Ну, если коротко. У icpp нет короткого цикла разработки.
Поэтому, как бы мы не нумеровали версии, все равно это будет неинформативно. Положим, Артур при фиксации 3606 изменил бы major номер версии. Какую информацию он бы этим добавил? - Осторожно, обратная совместимость пострадала
Все.
Ни данных о стабильности, ни о том, какая именно совместимость пострадала, здесь нет. Т.е. все равно ты вынужден - изучать описание изменений, чтобы найти источник несовместимости - искать стабильную версию среди последующих сборок
На мой взгляд - такое использование major номеров не сильно полезно. Другое дело, если major номер говорит: - вот, это результат завершенного цикла разработки, пользуйтесь на здоровье - он экстенсивно оттестирован и разработчиками, и пользователями - он прошел период обкатки, в течение которого не выявлено критических рекламаций - он содержит (список) нерешенных некритичных задач (мне не нравится слово "bug", я за слово "issue") - он содержит (список) несовместимостей с предыдущей версией
Но icpp - маленький проект, я не думаю, что нужно настолько формально заморачиваться. Непрерывный цикл разработки в текущем виде отлажен и дает неплохие результаты.
Я бы просто предложил создать отдельную "историю возникновения несовместимостей", можно в wiki. В формате "номер версии", "описание привнесенной и зафиксированной постоянно несовместимости".
Такую же табличку я бы завел для "обнаруженные критические проблемы". В формате "номер версии", "номер проблемы (bugzilla id)", "исправлено в версии".
Вот этого действительно не хватает, а стоимость поддержки - небольшая. А major номера оставил бы все же для фиксации завершенных циклов разработки.
|