Когда я должен увеличить номер версии?

Я не изучал программирование в школе, и я не работаю (профессиональным) разработчиком, поэтому многие основы мне не совсем понятны. Этот вопрос пытается уточнить один из них.

Теперь давайте предположим, что у меня есть проблемы #1, #2и #3в моем трекере проблем, которые настроены для исправления / улучшения для версии 1.0.0и что последняя (стабильная) версия является 0.9.0.

Когда я должен перейти к версии 1.0.0? Когда а) закрыта только одна из перечисленных выше проблем или б) когда закрыты все проблемы, связанные с версией 1.0?

Какой правильный способ сделать это? И по правильному пути я имею в виду то, что в настоящее время используется в промышленности.

Я могу рассказать вам, как я делаю это на работе.

У нас есть сервер непрерывной интеграции, который создает, тестирует, маркирует и выводит версионный пакет. Мы переходим к следующему этапу только в том случае, если предыдущий был успешным на 100%.

Наша версия выглядит следующим образом: <Major Version>. <Minor Version>. <Build Number>

• Каждая успешная сборка, в которой нет завершенного исправления ошибки или улучшения функции, увеличивает номер сборки.
• Каждая успешная сборка с завершенным исправлением ошибки или улучшением функции увеличивает Незначительную Версию. Это автоматически обнаруживается по наличию сообщения фиксации, использующего определенный формат. Это сообщение о коммите также автоматически попадает в проекты ChangeLog.
• Каждое увеличение основной версии выполняется вручную, когда мы имеем несовместимые изменения, переписываем с нуля или по другим причинам, сделанным на индивидуальной основе.

Номера версий относятся только к релизам , поскольку они позволяют внешним пользователям определять конкретную сборку вашего программного обеспечения. Если вы просто заняты разработкой и не выпускаете каждое исправление по отдельности, не беспокойтесь об увеличении номера выпуска для каждого исправления. Это не относится к внешним пользователям и тратит впустую ваше время с дополнительной версией бухгалтерии.

Для непрерывно развертываемых веб-приложений мы стремимся создавать номера сборок, используя symver, и номер номера сборки, то есть: 2.5.3.4328, где 4328 происходит из системы непрерывной интеграции. Общее ожидание состоит в том, что числа изменяются преднамеренными шагами, но что номер сборки является истинным уникальным идентификатором.

Похоже, что здесь делается захват дня развертывания и соответствующего номера сборки svn:

        <div id="svnrev">
            rev 2013.10.21.1078
        </div>

Для чего это стоит.

Другие ответы уже хороши, поэтому я добавлю только их сверху. Если ваше программное обеспечение не выпущено и вам не нужно публичное управление версиями (непубличное управление версиями - ваша VCS), добавьте ключевое слово « SNAPSHOT » в конце вашей версии. Некоторые системы, особенно в управлении зависимостями, обрабатывают моментальные снимки иначе, чем выпущенные версии, так как они сравнивают дату изменения моментальных снимков вместо номера версии. Таким образом, если в репозитории у вас был v. 1.0.0-SNAPSHOT с 8:00, а локальный загрузчик зависимостей имеет ту же версию с 7:00, то следует загрузить обновленную из репозитория.

Как сказано выше, ваша личная версия обеспечивается вашей системой контроля версий (git, svn и т. Д.).

Там достаточно сказано о теории управления версиями, вот еще одна точка зрения.

Когда я должен перейти на версию 1.0.0?

Я собираюсь сосредоточить свой ответ на смене номера основной версии.

Мой ответ: в основном, когда вы к этому готовы. Переход с 0,9 на 1,0 - это большая вещь, потому что общественное мнение будет о том, что вы переходите от бета-продукта к официальному релизу.

(Я предполагаю, что это коммерческий продукт компании).

Несколько вопросов перед переходом от 0,9 до 1,0.

Есть ли у вашей организации время для информирования всех ваших текущих клиентов. Устроить вечеринку. Получите много запросов поддержки. Менеджер по работе с клиентами, чтобы продать ваш продукт? И т. Д.

Да, я рассматриваю управление версиями как маркетинговый инструмент, и если вы посмотрите вокруг, то увидите, что это в основном отраслевой стандарт.

Наша компания перешла с версии 2.x на 3.0 и устроила отличную вечеринку, произвела много шума и благодаря этому приобрела немало новых клиентов. Помимо некоторых обновлений интерфейса различия между версиями были довольно незначительными.