tisha, Нумерация версий ПО для новичков и не только
Еще есть два вида недодела:
— пример 7-zip — вечная бета, никто ни за что не отвечает;
— пример GoogleChrome — добавили пару штрихов — новая версия.
Уж лучше золотая середина между ними.
лис.хвост
VIP
Разработчик
Dragokas
Angry https://www.safezone.cc/threads/princip-formirovanija-nomera-versii-programmy.25926/» target=»_blank»]www.safezone.cc[/mask_link]
Как правильно нумеровать версии программы
Нумерация версий ПО для новичков и не только
Мне известно достаточно много разработчиков, которые не могут понять (лень) как же нумеруются версии.
Иногда нужно просто сесть и разобраться, конечно в сети есть куча информации, но иногда ее слишком много, а где-то наоборот. Хочу поделиться как обстоят дела с нумерацией ПО у нас, манера изложения понятна и доступна даже простому пользователю, которому так же не плохо знать, что же обозначают эти странные циферки после названия программы.
Оглавление в Word с авто-нумерацией – Делаем правильно!
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] – условное обозначение релиза.
Совокупность главного и вспомогательного номеров версии (A.B) дают информацию о функционале приложения. Главный номер версии увеличивается только при очень серьёзном изменении функционала. Пользователи, купившие продукт и оплатившие техническую поддержку получают новые версии только в рамках постоянного главного номера версии, соответственно при выпуске новой главной версии пользователи не смогут получить её в рамках технической поддержки и будут вынуждены оплачивать её покупку заново.
Номер билда (С) должен увеличиваться (зачастую) руководителем проекта по разработке всякий раз, когда продукт передаётся на тестирование.
Номер ревизии (D) увеличивается системой контроля версий (SVN) автоматически при работе с ней. Задача руководите проекта по разработке синхронизировать номер ревизии, генерируемый SVN, с номером указанным в AssemblyInfo в модулях проекта. Выполнять эту операцию нужно одновременно с увеличением номера билда (С).
Обозначение релиза соответствует этапу работы над проектом в рамках жизненного разработки. Выделяют следующие релизы:
• Pre-alpha (pa) – соответствует этапу начала работ над версией. Характеризуется большими изменениями в функционале и большим количеством ошибок. Pre-alpha релизы не покидают отдела разработки ПО.
• Alpha (a) – соответствует этапу завершения разработки нового функционала. Начиная с alpha версии новый функционал не разрабатывается, а все заявки на новый функционал уходят в план работ по следующей версии. Этап характеризуется высокой активностью по тестированию внутри подразделения разработки ПО и устранению ошибок.
Нумерация с 4 страницы
• Beta (b) – соответствует этапу публичного тестирования. Это первый релиз, который выходит за пределы отдела разработки ПО. На этом этапе принимаются замечания от пользователей по интерфейсу продукта и прочим найденным пользователями ошибкам и неточностям.
• Release Candidate (rc) – весь функционал реализован и полностью оттестирован, все найденные на предыдущих этапах ошибки исправлены. На этом этапе могут вноситься изменения в документацию и конфигурации продукта.
• Release to manufacturing или Release to marketing (rtm) – служит для индикации того, что ПО соответствует всем требованиям качества, и готово для массового распространения. RTM не определяет способа доставки релиза (сеть или носитель) и служит лишь для индикации того, что качество достаточно для массового распространения.
• General availability (ga) – финальный релиз, соответствующий завершению всех работ по коммерциализации продукта, продукт полностью готов к продажам через веб или на физических носителях.
• End of life (eol) – работы по развитию и поддержке продукта завершены.
В скобках указаны сокращения, используемые для формирования номера релиза. Если в номере не указано ни одного сокращения, то считается что это релиз General availability (ga).
Помимо сокращённого обозначения в наименовании версии обозначение релиза должно указываться в исходных файлах проекта через атрибут:
В случае большого количества проектов в решении рекомендуется использовать один файл GlobalAssemblyInfo.cs (или GlobalAssemblyInfo.vb) с указанием ссылки на него во всех проектах решения и именно в нём проставлять вид релиза.
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. Имя файла дистрибутива
Имя дистрибутива должно однозначно указывать продукт и полный номер версии.
При сборке дистрибутива как набора несжатых файлов корневая папка, в которой располагаются подпапки и несжатые файлы дистрибутива именуется по формату
При сборке дистрибутива как msi-файла, msi-файл должен переименовываться в
При сжатии в архив каталога с файлами дистрибутива архив должен именоваться аналогично:
Upd: Такой принцип нумерации версий использует большинство разработчиков десктопных приложений.
- Среда для быстрого простого программирования с графикой Processing
- Как нумеровать версии программ
- Простой движок для написания игр на языке C под Linux
- QB64- Нативный QBasic под линукс.
Источник: webhamster.ru
Правильная нумерация ПО?
Есть версия ПО 2.9.9 Нужно выпустить новую версию, при этом не хотелось бы переходить на 3.0 Так и не смог разобраться, под какой версией выпустить ПО? 2.9.10? 2.10.1? 2.9.91? Да так, чтобы было понятно людям, что эта версия новее предыдущей.
Отслеживать
задан 7 мар 2017 в 23:10
81 5 5 бронзовых знаков
Может, 2.9.9.1 ? 🙂
7 мар 2017 в 23:26
etki, я, не знаю, может или нет, но почему здесь тогда пишут ru.wikipedia.org/wiki/… что 1.01 < 1.1 = 1.10 < 1.11 < 1.2 = 1.20. В итоге получается, что 2.10 меньше чем 2.9
7 мар 2017 в 23:36
8 мар 2017 в 0:12
когда коту заняться нечем.
9 мар 2017 в 7:29
2 ответа 2
Сортировка: Сброс на вариант по умолчанию
Проблема: вы руководствуетесь принципами визуальной упорядоченности при установке версии. Версионирование не имеет никаких связей с визуальной упорядоченностью.
Конфликт: вы не можете выбрать между виузальной упорядоченностью, которая говорит вам сделать 3.0.0, и принципом мажорного релиза, который осознаете скорее всего по-своему, но понимаете, что мажорный релиз это не «когда все цифры после первой становятся девятками».
Решение: выбрать только одно из двух, потому что принцип мажорной версии запрещает вам скакать, как получится, а визуальная упорядоченность не дает вам использовать двузначное число в качестве одного из компонентов версии.
Как все-таки хоть немного программист я могу лишь призвать сделать выбор в пользу разумного назначения версии. Насколько понял, вы уже читали про семантическое версионирование, но, судя по комментарию, думаю, что попытаться адаптировать конвенцию для вас стоит.
Семантическая версия состоит из трех номеров: major, minor, patch. Они различаются следующими вещами:
- patch-версия инкрементируется при выпуске релиза, закрывающего баги
- minor-версия инкрементируется при выпуске релиза с новым функционалом, не затрагивающем старый
- major версия инкрементируется при выпуске релиза, которым невозможно пользоваться так, как прежде
Поэтому определение «какую версию мне использовать» превращается в довольно простой условный блок:
- Релиз содержит только багфиксы? Инкрементируется patch-компонент, 2.9.10
- Релиз содержит нововведения, но старый функционал остался прежним? 2.10.0
- Релиз содержит нововведения, которые меняют способ использования старого функционала? 3.0.0
Отвечая на вопрос, который тут же появляется — «мне что, инкремнтировать major-версию каждый раз, когда я ломаю обратную совместимость?». Ответ на этот вопрос — да, major-версия должна выпускаться каждый раз, когда какие-то вещи ломаются; это не игра в поддавки и визуальную упорядоченность. Если вас заботит скорость выпуска major-версий — это значит, что вы ломаете слишком много вещей, и какие-то обновления стоит придерживать в ветке до того, как появится моральная готовность выпустить новый major-релиз; на адаптацию к этой модели уйдет некоторое время, но на деле это всего лишь цифры, между которыми нет никакой разницы, версия 2.х.х или 17.х.х — для конечного потребителя это не так важно как то, сможет ли он пользоваться новой версией так же, как старой.
Не пытайтесь воспринимать 2.9.9. как 299. Это не число и не поддается правилам инкрементирования чисел.
Источник: ru.stackoverflow.com