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

23

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

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

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

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

versioning semantic-versioning Ahmed
источник
22
Смотрите semver.org
Мартейн Питерс
1
И вы можете включить все три вопроса в свой следующий выпуск.
Мартин Питерс
Да, я уже использую SemVer, и в следующем выпуске появятся ВСЕ три вопроса :)
Ахмед
Я отредактировал вопрос, чтобы избежать путаницы.
Ахмед

Ответы:

15

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

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

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

  • Каждая успешная сборка, в которой нет завершенного исправления ошибки или улучшения функции, увеличивает номер сборки.
  • Каждая успешная сборка с завершенным исправлением ошибки или улучшением функции увеличивает Незначительную Версию. Это автоматически обнаруживается по наличию сообщения фиксации, использующего определенный формат. Это сообщение о коммите также автоматически попадает в проекты ChangeLog.
  • Каждое увеличение основной версии выполняется вручную, когда мы имеем несовместимые изменения, переписываем с нуля или по другим причинам, сделанным на индивидуальной основе.
dietbuddha
источник
Но если у вас есть ряд улучшений для <Minor Version>, например 1.0.0. Нужно ли делать ВСЕ эти улучшения, чтобы иметь возможность сказать «ОК! Теперь это версия 1.0.0», или вы увеличиваете до версии 1.0.0, как только будет выполнено первое улучшение?
Ахмед
@ahmed Я видел подход, который 1.4.2называется «этот набор исправлений и все остальное готово в то время» ... Я также видел 1.4.2как «Это будет выпущено в эту дату с тем, что готово». Это зависит от вашего цикла выпуска.
5
@ahmed Если критерием перехода от 0.xx к 1.xx было завершение набора функций / исправлений, то я увеличил бы их только после их завершения. Обратите внимание: мы вообще так не работаем. Мы не нацеливаемся на версию и решаем, какие исправления в ней. Мы нацелены на исправления. Версия, которую мы получаем, предназначена исключительно для отслеживания и идентификации, а не для цели.
dietbuddha
Это именно то, что я хотел знать :)
Ахмед
21

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

Грег Хьюгилл
источник
Относится ли это также к веб-разработке, где выпуск может быть простым исправлением незначительной ошибки?
Ахмед
4
Вы делаете QA перед выпуском исправления? Это релиз. Если не полный продукт, то исправления.
Питер К.
@ahmed В таком сценарии номера версий часто невидимы для пользователя и, следовательно, бессмысленны (номера версий в основном существуют для маркетинговой и технической поддержки, которые не применяются для многих веб-приложений). Достаточно просто использовать идентификатор фиксации. Если вы настаиваете на использовании номеров версий, да, я бы, вероятно, увеличил уровень исправления.
Амон
Здесь я многому учусь: p Итак, подведем итог: мне НЕ нужны номера версий, так как достаточно идентификаторов коммитов, поскольку ВСЕ пользователи все равно будут использовать последнюю версию.
Ахмед
2
Хотя все пользователи используют одну и ту же версию, к тому времени, как вы посмотрите отчет о дефектах, версия переместится. Вам все еще нужен способ привязать отчет к определенной сборке программного обеспечения (дата и время могут быть достаточно хорошими).
Mattnz
2

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

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

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

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

Уайетт Барнетт
источник
0

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

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

Хьюберт Гжесковяк
источник
0

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

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

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

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

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

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

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

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

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

Питер Б
источник