Как сделать номера версий?

Question

Моя компания строит продукт. Это будет версия от SVN. Это веб-приложение, поэтому, по сути, никогда не будет версии, которая не имеет каких-либо функций и поэтому всегда может быть помечена как бета-версия. Но так как это будет корпоративный продукт, я действительно не хочу, чтобы там были "нестабильные наблюдатели". Так как бы вы занялись версионированием? 1.0 стабильна? Дата сборки должна быть в номере версии? Скажите, что вы, ребята, думаете!

Answer 1

Хотя переход на номер редакции Subversion приятен и прост, он удаляет информацию из номера версии. Пользователи могут подумать, что это плохо.

Я предполагаю, что ваше веб-приложение будет иметь какую-то процедуру развертывания, так что не каждая ревизия в Subversion действительно публикуется. Поскольку невозможно «извне» (с точки зрения пользователя) определить, когда делаются выпуски и сколько ревизий в них будет вносить код, это делает числа почти случайными. Они будут увеличиваться, и я думаю, что можно предположить некоторую дистанцию ​​от сравнения двух ревизий, но не очень.

Классические номера версий имеют тенденцию «драматизировать» релизы, так что пользователи могут строить какие-то ожидания. Проще подумать: «У меня версия 1.0, сейчас версия 1.1 добавлена ​​и то, и это звучит интересно», чем думать, что вчера мы запустили SO ревизию 2587, сегодня она 3233, она должна быть намного лучше! ».

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

Answer 2

Управление версиями зависит от вас; Я бы поставил 1.0 на первую версию, в которой я был уверен. Возможно, вы захотите быстро продолжить ее с другими версиями, поскольку некоторые поставщики программного обеспечения дали 1.0 плохую репутацию.

Вы хотите каким-то образом связать номер версии с точной используемой сборкой, но вы, вероятно, хотите, чтобы он был приятным и простым для ваших конечных пользователей. Попробуйте использовать стандартные номера версий и пометить SVN-репозиторий включенным номером версии.

Answer 3

Мы потратили слишком много времени, решая, когда увеличить основную версию. Некоторые магазины редко делают это, поэтому у вас будут выпуски, такие как 1.25.3, а другие будут делать это всегда, давая вам 15.0

.

Я сыт по горло этим и убедил всех, что номер основного релиза - это только год, а младший - просто последовательный релиз в течение года. Похоже, пользователям это понравилось, и придумать следующий номер версии не составит труда.

Year.Release.build

• год = текущий год
• release = последовательность # публичных релизов с новый функционал - сбросить до 1 каждый год
• build = увеличен для ошибки исправления и внутренние выпуски

РЕДАКТИРОВАТЬ

** Теперь это было для внутреннего приложения, которое постоянно улучшалось **

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

Answer 4

Хорошая информация здесь:

Когда изменять файл / версии сборки

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

Сборки без доставки В целом, я рекомендую сохранять версии сборок, не относящихся к отправке, одинаковыми между сборками. Это позволяет избежать проблем с загрузкой сборок со строгими именами из-за несоответствия версий. Некоторые люди предпочитают использовать политику издателя для перенаправления новых версий сборок для каждой сборки. Однако я рекомендую это делать для сборок без доставки: это не позволяет избежать всех проблем с загрузкой. Например, если партнер ксерокопирует ваше приложение, он может не знать, как установить политику издателя. Тогда ваше приложение будет сломано для них, даже если оно отлично работает на вашем компьютере.

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

Доставка строений Относительно того, стоит ли менять эту версию для доставки сборок, зависит от того, как вы хотите, чтобы привязка работала для конечных пользователей. Вы хотите, чтобы эти сборки были рядом или на месте? Много ли изменений между двумя сборками? Они собираются сломать некоторых клиентов? Вы заботитесь о том, чтобы это сломало их (или вы хотите, чтобы пользователи использовали ваши важные обновления)? Если да, вам следует рассмотреть возможность увеличения версии сборки. Но, опять же, учтите, что выполнение этого слишком много раз может засорить пользовательский диск устаревшими сборками.

При изменении версий сборки Чтобы заменить жестко закодированные версии на новые, я рекомендую установить переменную в версию в заголовочном файле и заменить жесткое кодирование в источниках переменной. Затем запустите препроцессор во время сборки, чтобы установить правильную версию. Я рекомендую менять версии сразу после доставки, а не прямо перед этим, чтобы у вас было больше времени для выявления ошибок из-за изменений.

Answer 5

Мы используем простой синтаксис major.minor.julian_date.

Где;

• Major - Первый выпуск равен 1, а затем, когда мы представляем новые важные функции или изменения, настолько значимые, что они несовместимы с предыдущими версиями, увеличиваем это число.
• Незначительный - Основные релизы. Для каждой сборки, запущенной производством, это число увеличивается.
• julian_date - Юлианский день сборка была отправлена ​​в QA.

Пример первого выпуска, отправленного в QA 1/15, -> 1.0.015
Пример первого выпуска, переведенного в производство 3/4, -> 1.1.063

Он не идеален, но удобен, так как мы приближаем ежедневные сборки к QA.

Answer 6

Причина, по которой этот вопрос существует, заключается в том, что у нас нет единого согласованного способа управления конфигурацией.

Мне нравится делать номер версии, просто увеличивая число на 1. Я не хочу, чтобы номер версии состоял из нескольких частей, которые мне придется объяснять или документировать. И я не хочу использовать номер версии SVN, поскольку это также потребует некоторых пояснений.

Чтобы это произошло, вам понадобятся несколько скриптов релиза поверх SVN

Answer 7

У меня очень мало опыта в этой области. Однако вот что я бы сделал:

1. Выберите схему для нумерации ревизий и придерживайтесь ее. Быть последовательным.
2. Каждое изменение версии должно представлять значительное изменение . Насколько значительным является изменение, и уровни изменений, отраженные в номере версии, зависят от вас.

Конечно, вы можете просто использовать номер ревизии SVN - как и многие другие предлагали !!!

Надеюсь, это поможет.

Answer 8

Или использовать ваш «продуманный» номер версии с запятой подрывной деятельности .. z.B.:

1.0.101 // редакция 101, выпуск

или 1.0.101-090303 // с датой выпуска, я использую это