close

Вход

Забыли?

вход по аккаунту

?

СИСТЕМЫ УПРАВЛЕНИЯ ВЕРСИЯМИ

код для вставкиСкачать
Нумерация версий ПО для новичков и не только
СИСТЕМЫ УПРАВЛЕНИЯ ВЕРСИЯМИ
Нумерация версий ПО для новичков и не только
Вместо введения
Мне известно достаточно много разработчиков, которые не могут понять (лень) как же нумеруются версии.
Иногда нужно просто сесть и разобраться, конечно в сети есть куча информации, но иногда ее слишком много, а где-то наоборот. Хочу поделиться как обстоят дела с нумерацией ПО у нас, манера изложения понятна и доступна даже простому пользователю, которому так же не плохо знать, что же обозначают эти странные циферки после названия программы.
2. Формат номера версии
Формат номера версии A.B.C.D[r], где:
• A - главный номер версии (major version number).
• B - вспомогательный номер версии (minor version number).
• C - номер сборки, номер логической итерации по работе над функционалом версии A.B (build number).
• D - Номер ревизии, сквозной номер назначаемый автоматически программным обеспечением хранения версий (SVN). Номер ревизии SVN должен синхронизироваться с номером ревизии в AssemblyInfo при каждой сборке релиза (revision number).
• [r] - условное обозначение релиза.
2.1. A.B
Совокупность главного и вспомогательного номеров версии (A.B) дают информацию о функционале приложения. Главный номер версии увеличивается только при очень серьёзном изменении функционала. Пользователи, купившие продукт и оплатившие техническую поддержку получают новые версии только в рамках постоянного главного номера версии, соответственно при выпуске новой главной версии пользователи не смогут получить её в рамках технической поддержки и будут вынуждены оплачивать её покупку заново.
2.2. C
Номер билда (С) должен увеличиваться (зачастую) руководителем проекта по разработке всякий раз, когда продукт передаётся на тестирование.
2.3. D
Номер ревизии (D) увеличивается системой контроля версий (SVN) автоматически при работе с ней. Задача руководите проекта по разработке синхронизировать номер ревизии, генерируемый SVN, с номером указанным в AssemblyInfo в модулях проекта. Выполнять эту операцию нужно одновременно с увеличением номера билда (С).
2.4. [r]
Обозначение релиза соответствует этапу работы над проектом в рамках жизненного разработки. Выделяют следующие релизы:
• Pre-alpha (pa) - соответствует этапу начала работ над версией. Характеризуется большими изменениями в функционале и большим количеством ошибок. Pre-alpha релизы не покидают отдела разработки ПО.
• Alpha(a) - соответствует этапу завершения разработки нового функционала. Начиная с alpha версии новый функционал не разрабатывается, а все заявки на новый функционал уходят в план работ по следующей версии. Этап характеризуется высокой активностью по тестированию внутри подразделения разработки ПО и устранению ошибок.
• Beta (b) - соответствует этапу публичного тестирования. Это первый релиз, который выходит за пределы отдела разработки ПО. На этом этапе принимаются замечания от пользователей по интерфейсу продукта и прочим найденным пользователями ошибкам и неточностям.
• Release Candidate (rc) - весь функционал реализован и полностью оттестирован, все найденные на предыдущих этапах ошибки исправлены. На этом этапе могут вноситься изменения в документацию и конфигурации продукта.
• Release to manufacturing или Release to marketing (rtm) - служит для индикации того, что ПО соответствует всем требованиям качества, и готово для массового распространения. RTM не определяет способа доставки релиза (сеть или носитель) и служит лишь для индикации того, что качество достаточно для массового распространения.
• General availability (ga) - финальный релиз, соответствующий завершению всех работ по коммерциализации продукта, продукт полностью готов к продажам через веб или на физических носителях.
• End of life (eol) - работы по развитию и поддержке продукта завершены.
В скобках указаны сокращения, используемые для формирования номера релиза. Если в номере не указано ни одного сокращения, то считается что это релиз General availability (ga).
Помимо сокращённого обозначения в наименовании версии обозначение релиза должно указываться в исходных файлах проекта через атрибут:
[AssemblyConfiguration]
В случае большого количества проектов в решении рекомендуется использовать один файл GlobalAssemblyInfo.cs (или GlobalAssemblyInfo.vb) с указанием ссылки на него во всех проектах решения и именно в нём проставлять вид релиза.
Пример С#:
using System.Reflection;
[assembly: AssemblyConfiguration("Beta")]
Пример VB.NET:
Imports System.Reflection
<Assembly: AssemblyConfiguration ("General availability")>
2.5. Примеры
HBR 2.3.1.1260b - релиз HBR версии 2.3, сборка 1, ревизия 1260, бета.
HBR 2.3.2.1370rc - релиз HBR версии 2.3, сборка 2, ревизия 1370, релиз-кандидат.
HBR 2.3.5.1432 - релиз HBR версии 2.3, сборка 5, ревизия 1432, ga-релиз.
3. Версии модулей/аддинов
Если в составе ПО выделены модули или аддины, то можно применять два подхода к ведению номеров их версий.
1. Синхронная нумерация - нумерация модулей и аддинов совпадает с версией самого приложения.
2. Индивидуальная нумерация - нумерация версии модуля или аддина ведётся индивидуально как для отдельного самостоятельного приложения.
Первый подход рекомендуется применять на этапе активной разработки приложения до выхода первого ga-релиза в текущей версии. Если функционал модуля устоялся и не требует изменений при развитии других модулей или самого приложения, то рекомендуется применять второй подход.
4. Имя файла дистрибутива
Имя дистрибутива должно однозначно указывать продукт и полный номер версии.
При сборке дистрибутива как набора несжатых файлов корневая папка, в которой располагаются подпапки и несжатые файлы дистрибутива именуется по формату "<Имя продукта> A_B_C_D[r]".
При сборке дистрибутива как msi-файла, msi-файл должен переименовываться в "<Имя продукта> A_B_C_D[r]".
При сжатии в архив каталога с файлами дистрибутива архив должен именоваться аналогично: "<Имя продукта> A_B_C_D[r]".
Upd: Такой принцип нумерации версий использует большинство разработчиков десктопных приложений. комментарии (51)
* o o olegych76, o 17 мая 2011, 10:41 o # o ↓
o * +1
* Отлично! Информативно, положил в закладки. * o o mark_ablov, o 17 мая 2011, 10:45 o # o ↓
o * 0
* еще бывает нумеруют RC.
например rc~2 или просто rc2 o * * ifmalex, * 17 мая 2011, 10:55 * # * ↑
* ↓
* * 0
* В пункте 2.4. [r] как раз упоминается об этом. o * * UseRifle, * 17 мая 2011, 10:57 * # * ↑
* ↓
* * +3
* ну у каждой команды свои заморочки... * o o Klu4nik, o 17 мая 2011, 10:53 o # o ↓
o * 0
* У нас в фирме нумеруют немного странно.
например изначальная версия ПО была 2.0.1.
Последняя цифра номер версии в текущей сборке, после существенных изменений идет смена второго номера например версия 2.1.0 или 2.1.1. Первая цифра показывает поколение ПО.
Беты, альфы и гаммы обозначаются просто пометкой. * o o Doomsday_nxt, o 17 мая 2011, 10:54 o # o ↓
o * +3
* а мне нравится нумерация типа: 11.05.17.1
11 - год
05 - месяц
17 - число
1 - ревизия o * * olegych76, * 17 мая 2011, 10:58 * # * ↑
* ↓
* * 0
* Это с одной стороны крайне удобно, т.к. четко дает понять о состоянии выпуска, но все же не хватает именно идентификатора статуса релиза. Ревизия, по-моему, слишком размыто. А вот если соединить оба метода - тогда да, совсем отпадают вопросы.
Хотя, конечно, много цифр смущают многих. * * * Doomsday_nxt, * 17 мая 2011, 12:54 * # * ↑
* ↓
* * 0
* как вариант: 1.2.110517.1
по сути стандартный A.B.C.D, тока вместо номера билда - дата создания этого билда...
но да, много цифр :-) o * * den_rad, * 17 мая 2011, 11:26 * # * ↑
* ↓
* * +6
* Если у вам нужно будет закрыть дырки в старой версии продукта, то номер у нее будет сбивать всех с толку. * * * bethrezen, * 17 мая 2011, 15:20 * # * ↑
* ↓
* * 0
* Microsoft для этого придумали нумерацию обновлений и service pack. Но у них и цикл релизов другой.
Gentoo решает эту проблему устанавливая версии на конкретные компоненты.
Тут уже имхо надо исходить из сути продукта. o * * lavel, * 17 мая 2011, 11:48 * # * ↑
* ↓
* * 0
* В паре с подробным changelog`ом это самая удобная нумерация\история версий, на мой взгляд конечно же. o * * oWeRQ, * 17 мая 2011, 13:59 * # * ↑
* ↓
* * 0
* Только лучше без числа, редко выпускается версия каждый день. * * * Doomsday_nxt, * 17 мая 2011, 17:21 * # * ↑
* ↓
* * 0
* при достаточно интеснсивной разработке (например, непосредственно перед релизом) билды могут быть очень частыми... o * * Qbit, * 17 мая 2011, 15:20 * # * ↑
* ↓
* * 0
* > а мне нравится нумерация типа: 11.05.17.1
Сколько было мажорных версий между 09.12.17 и 11.01.12?
Какая версия была впритык перед 10.03.27?
А 10.09.09 - это очень старая версия?
Приведённая нумерация не даёт возможности ответить на эти вопросы. * * * Doomsday_nxt, * 17 мая 2011, 17:16 * # * ↑
* ↓
* * 0
* приведенные вопросы лично мне как пользователю ПО никогда не были интересны и не будут интересны...
мне гораздо интереснее знать - когда был последний релиз... * * * Qbit, * 17 мая 2011, 17:38 * # * ↑
* ↓
* * 0
* > когда был последний релиз
Для этого есть ReleaseNotes. Зачем такую второстепенную информацию, как дата релиза, делать ключом? * * * Doomsday_nxt, * 17 мая 2011, 17:17 * # * ↑
* ↓
* * 0
* И да, какая нумерация даёт ответ на последний вопрос? По моему мой вариант как раз точнее даёт ответ на этот вопрос :-) * * * Qbit, * 17 мая 2011, 17:30 * # * ↑
* ↓
* * 0
* >> А 10.09.09 - это очень старая версия?
> И да, какая нумерация даёт ответ на последний вопрос? По моему мой вариант как раз точнее даёт ответ на этот вопрос :-)
Меня не интересует "возраст" в календарном смысле, важнее прирост функционала. Если нумерация соблюдается последовательно, то между версиями 2.1.0, 2.2.0, 2.3.0, 2.4.0 будет ожидаться примерно равный прирост функционала. Даже если первые две были сделаны три года назад, а последние две - в этом году. В другом случае: кажется, что между версиями 08.09.30 и 11.04.29 прошло много времени, а на самом деле в последнем релизе был небольшой фикс, и при нормальной нумерации они были бы 2.1.0.1114 и 2.1.0.1120 соответственно.
Равномерность нумерации версий и равномерность течения времени - разные вещи. При нормальной нумерации как правило нет "пробелов", а по оси времени между версиями теоретически может стоять непредсказуемое число промежуточных версий. * * * Doomsday_nxt, * 17 мая 2011, 17:41 * # * ↑
* ↓
* * 0
* т.е. вы хотите сказать что по "2.4.0" можно сказать насколько стара эта версия?
выше я уже предложил вариант отвечающий вашим требованиям...
к тому же я не заставляю вас использовать мой вариант нумерации... мало того - я считаю что над ним надо еще подумать и поработать... * * * Qbit, * 17 мая 2011, 17:46 * # * ↑
* ↓
* * +1
* > т.е. вы хотите сказать что по "2.4.0" можно сказать насколько стара эта версия?
Да. Если текущая версия 2.4.3, то версия 2.4.0 не очень стара (даже если выпущена три года назад). Если текущая версия 5.0.1, то верся 2.4.0. скорее всего очень стара, даже если её релиз был в начале прошлого года.
Если текущая версия 11.05.17, то ты не сможешь сказать, стара ли версия 10.02.09. * o o Shedal, o 17 мая 2011, 11:03 o # o ↓
o * 0
* У нас корпоративное веб-приложение, и клиентам показывается только версия формата A.B, а внутри используем такую форму записи: 3.12.86.1234, где 86 - тип процессора, а 1234 - ревизия системы контроля версий.
P.S. Спасибо за статью, вот только из нее не совсем понятно, насколько она применима к проектам, отличным от вашего. Было бы хорошо увидеть фразу типа: "такую систему нумерации использует большинство разработчиков десктопных приложений" (если так и есть). o * * ifmalex, * 17 мая 2011, 11:15 * # * ↑
* ↓
* * 0
* Так и есть (бо́льшая часть знакомых именно так нумеруют).
PS: Дописал, спасибо! * o o pomkaster, o 17 мая 2011, 11:21 o # o ↓
o * -7
* А мне честно говоря не совсем понятно для чего нужна вообще нумерация версий. Кроме как показать что версия 1.0 по функционалу хуже чем версия 2.0 (хотя зачастую это не так). o * * mgrach, * 17 мая 2011, 15:17 * # * ↑
* ↓
* * +1
* Люди любят обновления. Люди любят, когда о них заботятся. Новые версии - это проявление заботы. Изменение циферок - это хорошо, это значит, что тебя не забыли (: * o o remal, o 17 мая 2011, 11:24 o # o ↓
o * 0
* "Номер сборки" и "номер логической итерации" - разные понятия. Собираться проект (т.е. build'иться) может и каждую ночь, а то и чаще. o * * bethrezen, * 17 мая 2011, 15:37 * # * ↑
* ↓
* * 0
* А если одна итерация закончилась раньше другой? * o o alever, o 17 мая 2011, 11:37 o # o ↓
o * +1
* В пунктк 2.5 опечатка:
HBR 2.3.2.1370rc - релиз HBR версии 2.3, сборка 3, ревизия 1370, релиз-кандидат.
Там сборка 2.
o * * ifmalex, * 17 мая 2011, 11:46 * # * ↑
* ↓
* * 0
* Спасибо, поправил. * o o Jazzist, o 17 мая 2011, 11:38 o # o ↓
o * -2
* С почином! * o o eldarmusin, o 17 мая 2011, 11:45 o # o ↓
o * -1
* Спасибо за статью. Очень полезная для понимания обозначения версий. Google Chrome кстати её так же использует. * o o Averrin, o 17 мая 2011, 11:46 o # o ↓
o * +4
* А альфа разве не так пишется: alpha? o * * ifmalex, * 17 мая 2011, 11:53 * # * ↑
* ↓
* * 0
* Верно, специально смотрел как пишется, но так и не поправил. * o o tangro, o 17 мая 2011, 11:49 o # o ↓
o * +8
* >Задача руководите проекта по разработке синхронизировать номер ревизии, генерируемый SVN, с номером указанным в AssemblyInfo в модулях проекта.
Это не руководителя проекта задача, а скрипта, собирающего инсталяху продукта. Вполне автоматизируемая задача.
А вообще, не знаю как в других странах, но в Украине, например, если Вы меняете номер версии продукта - (даже в четвертой цифре) - это уже считается другой продукт, на него нужно отдельно оформлять авторские права, платить налоги и т.д. Куча времени, денег и бумажной волокиты. Потому наш флагманский продукт в версии 1.0 уже 5 лет находится. И только глубоко внутри и мелким шрифтом написаны минорная версия и номер ревизии. И называется это не "версия" как что-то типа "доп. инфо.". * o o imac, o 17 мая 2011, 11:52 o # o ↓
o * +3
* Забавный термин аддин, впервые услышал. o * * Bright, * 17 мая 2011, 12:47 * # * ↑
* ↓
* * 0
* Если не ошибаюсь, его использует в основном только Microsoft. * o o tranquil, o 17 мая 2011, 11:55 o # o ↓
o * +4
* сквозной номер назначаемый автоматически программным обеспечением хранения версий (SVN).
А что делать с dvcs, например, git?
Номер билда (С) должен увеличиваться (зачастую) руководителем проекта по разработке всякий раз, когда продукт передаётся на тестирование.
А если руководитель забыл увеличить, получаем 2 экземпляра программы с разным содержимым и одинаковой версией?
Upd: Такой принцип нумерации версий использует большинство разработчиков десктопных приложений.
Печально.
Если нужно версионить действительно понятно, есть более элегантные правила semver.org/. o * * ifmalex, * 17 мая 2011, 12:01 * # * ↑
* ↓
* * 0
* Я лишь изложил один из возможных вариантов. Каждый (каждая компания, группа, и т.д.) выбирает тот вариант, который удобен ей. * * * tranquil, * 17 мая 2011, 12:06 * # * ↑
* ↓
* * +1
* Я уже понял свою ошибку, по моей ссылке правила версионирования технические. Ваши же - частично маркетинговые. o * * tranquil, * 17 мая 2011, 12:04 * # * ↑
* ↓
* * +1
* Пользователи, купившие продукт и оплатившие техническую поддержку получают новые версии только в рамках постоянного главного номера версии, соответственно при выпуске новой главной версии пользователи не смогут получить её в рамках технической поддержки и будут вынуждены оплачивать её покупку заново.
Т.е. увеличение номера A не связано с техническими вопросами никак. Этот номер увеличивается тогда, когда компания решила что уже можно срубить с пользователей ещё немного денег.
Правильный подход, так действительно делает большинство. * o o megaweber, o 17 мая 2011, 12:11 o # o ↓
o * +5
* Буквально недавно была подобная статья: habrahabr.ru/blogs/development_tools/118756/ o * * Qbit, * 17 мая 2011, 15:24 * # * ↑
* ↓
* * +1
* Гораздо более толковая притом. * o o Akenfold, o 17 мая 2011, 12:15 o # o ↓
o * 0
* Очень напомнило Software Versioning из Википедии. Ранее я руководствовался этим материалом как некоторым эталоном. Но ваш пост содержит более полную информацию и много дополнительных полезных материалов. Хорошая работа. * o o eyeofhell, o 17 мая 2011, 12:18 o # o ↓
o * +1
* C и D разве не дублируют друг друга? Если не секрет, зачем одновременно иметь и номер билда и номер ревизии, если номера ревизии достаточно для однозначного определения билда? Тоесть чем принципиально 2.1.26.1845 отличается от 2.1.1845? o * * lesha_penguin, * 17 мая 2011, 19:53 * # * ↑
* ↓
* * -1
* В маленьких проектах (с коротким ходом итерации допиливание-тестирование) где C==D, нумерации A.B.C более чем достаточно.
Использование C!=D нужно там, где проект и его отдельные части, проходит разные стадии готовности, в которых задействованы много людей на разных фазах (т.е. пока отдел тестирования скажем тестировал 1.4.55.2301 номера ревизий уже могли далеко убежать, и например 1.4.55.2302... 1.4.55.2318 за пределами отдела разработки никто не видит, а следующая доработанная версия которая поступит в отдел тестирования будет например, уже 1.4.56.2501).
Соответственно, в мини-проектах "три с половиной файла" (например небольшая простая отдельная библиотека) над которыми работает "полтора человека" с лихвой хватает даже нумерации A.B а или иногда даже просто можно обойтись одним A==номер ревизии (вполне кстати подходит для вспомогательных библиотек для внутреннего пользования).
* * * eyeofhell, * 17 мая 2011, 20:09 * # * ↑
* ↓
* * +1
* пока отдел тестирования скажем тестировал 1.4.55.2301 номера ревизий уже могли далеко убежать, и например 1.4.55.2302... 1.4.55.2318 за пределами отдела разработки никто не видит, а следующая доработанная версия которая поступит в отдел тестирования будет например, уже 1.4.56.2501
Не совсем понятно. А что случится, если "скажем тестировал 1.4.2301 а следующая доработанная версия которая поступит в отдел тестирования будет, например, уже 1.4.2501"? * o o simplyv, o 17 мая 2011, 13:54 o # o ↓
o * -1
* Хорошая статья, по делу и без воды.
Понятно, что она не исчерпывающая. Подразумевается, что читатель что-то уже знает. Чего у нас в России не хватает, так это стандартов. Каждый делает, как ему кажется удобнее. А сейчас время стандартов, никто не собирается ничего изучать, все сразу должно быть понятно или очевидно. Так что статья тем более полезная. Спасибо. * o o Vidmak, o 17 мая 2011, 14:17 o # o ↓
o * +1
* Прочитал полезно, но спотыкался об слово функционал, в каждом втором предложении (функциональность?). А больше никто не спотыкается? o * * consumer, * 17 мая 2011, 15:14 * # * ↑
* ↓
* * 0
* Странно, почему людей раздражает "функционал"? Уже не раз это слышал. Почему не раздражает, наприер, "винт" или "база". Они же тоже имеют другие значения. * * * Vidmak, * 17 мая 2011, 15:34 * # * ↑
* ↓
* * +1
* Ну не то что бы сильно раздражает. Может другие значения "винт" и "база" совсем из других областей, и по мнению тех, кого это раздражает, те кто употребляют "функционал" не знакомы с математикой. Как вам такая версия? * * * consumer, * 17 мая 2011, 17:10 * # * ↑
* ↓
* * 0
* > Может [...] по мнению тех, кого это раздражает, те кто употребляют "функционал" не знакомы с математикой.
Откуда такое мнение, и почему это вообще имеет значение, знакомы или не знакомы с математикой? В данном контексте ведь речь совсем не о математике. То есть понятно, что ход мысли может быть примерно такой: 1) они например говорят про "проект", "продукт", и т.п. (не математика), и вдруг используют слово "функционал", 2) понятно что это слово в данном контексте не связано с математикой, но какие же они дураки что используют математический термин, и сами об этом не подозревают. Но почему сразу возникают именно такие мысли? Почему не возникает мысль, что люди и в самом деле могут знать про "функционал" из математики, но сейчас им не удобно говорить длинное слово "функциональность", если его можно удобно сократить. Так же как и "винт" вместо "винчестер".
Не подумайте что я придераюсь. Просто интересен феномен. * * * Vidmak, * 17 мая 2011, 17:16 * # * ↑
* ↓
* * 0
* Я тоже не понимаю, почему я спотыкаюсь об это слово. При этом я могу вообще в одном слове пять ошибок сделать и не заметить. 
Автор
SStalnyh
Документ
Категория
Информатика
Просмотров
254
Размер файла
75 Кб
Теги
Нумерация, разработка ПО, версии
1/--страниц
Пожаловаться на содержимое документа