Symfony2 + NelmioApiDoc, как бороться с changelog?

Question

[Twist]

Здравствуйте! Кто как борется с такой ситуацией?
Пример.
Пишем бэкенд для приложения/сайта не важно, и ребята которые отвечают за фронтенд не видят изменений которые бекендщики вносят в методы (добавление новых параметров, изменение старых, удаление). Несколько раз пытался делать changelog отдельным доковским файлом на google doc'ах, но быстро надоедает заполнение этих всех вещей.
Есть ли готовое решение? (нагуглить не получилось)
Есть ли желающие скооперироваться и написать надстройку, которая будет вести changelog, реализовать можно выпадающим списком вот здесь (см. скриншот)

Answer 1

[Сергей Протько]

А как вы себе это видите?

Если я правильно понимаю вашу проблему, вам нужно вводить версии API и при каждом новом релизе или изменении делать новую версию. Тогда организовать diff текущей и предыдущей версии будет не сложно.

Но без версионизации это довольно проблематично. Либо надо дампить состояние документаци на определенный момент а затем делать diff...

Идея сама по себе довольно интересная.

Comments

[Twist]

Сейчас в голове это все достаточно абстрактно крутится, но я представляю себе это примерно в таком виде. Мы должны делать слепок текущей доки и сравнивать с тем, что мы получили при последнем парсинге, после чего собственно добавлять элементы в changelog, который будет статичным файлом и просто будет хранить все изменения.

[Сергей Протько]

Юрий Левин: ну вот если придумать как хранить изменения то проблемы реализовать это дело особо нет. С другой стороны корректнее было бы воспользоватья версионизацией API. Это проще и правильнее, так как после релиза приложения и изменении API все пользователи которые не обновили приложение будут страдать ибо для них API работать не будет.

Короче нужно думать.

[Twist]

Сергей Протько: такой changelog был бы очень удобен на стадии разработки, т.к многое меняется в процессе и по этому к версионности это не совсем относится.

[Сергей Протько]

Юрий Левин: ну тогда главная проблема - где хранить этот самый лог.

Как я это вижу: делаем compile pass который берет текущую ревизию, берет новую, делает diff и сохраняет этот самый diff. Текущую ревизию можно делать как в SVN смерджив первую версию и все diff-ы за ним. Далее добавить консольную команду аля api:doc:changelog который сгенерит нормальный файл или же сделать web интерфейс.

Проблема в том, где все это хранить что бы это было надежно. В var/cache (или app/cache) не очень надежно так как cache:clear и у нас нет начальной точки.

Я в данный момент не вижу где можно хранить подобную информацию.

[Сергей Протько]

Юрий Левин: можно воспользоваться sqlite в принципе...

[Twist]

Сергей Протько: мне кажется, что для одного бандла достаточно будет и старого доброго .dat файла с информацией для парсинга, т.е 1 - строка, 1 запись. Ведь по сути у нас там будут хранится просто "новости" :-D

[Сергей Протько]

Юрий Левин: а где будет находиться этот самый .dat файл? Проблема именно в этом.

[Twist]

Сергей Протько: самое простое - генерить файл в директории web