LINUX.ORG.RU

Про версии продуктов


0

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 в модулях проекта. Выполнять эту операцию нужно одновременно с увеличением номера билда (С).

Итак, у меня есть моя поделка, а именно GrabVK. Первые ее версии именовались как 0.0.1, 0.0.2, 0.0.3 и т.д., что было бы вполне себе логично. Но теперь поделка перепиливается с нуля, полностью переписывается код и меняется функционал. Появилась первая более менее рабочая версия, которую нужно тестить, чем занимаются знакомые и просто народ с лоркода. Если следовать логике, описанной в статье, то версия должна быть 1.0.1 (ибо полностью все изменено (мажорная версия), первичный функционал только и первая сборка). Все последующие билды должны быть 1.0.2, 1.0.3 и т.д. Когда будет сделана следующая версия, содержащая в себе значительные изменения функционала (добавлен новый), то меняться должна средяя цифра, т.е. 1.1.1, 1.1.2, 1.1.3 и т.д. Я прав? Если нет - поясните как это по феншую, и в чем я не прав. Заранее спасибо.

★★★★★

Я нумерую «от балды», начиная с 0.0.1-1 до 0.0.1-9 или ~10, к 0.0.2 перехожу при значительном улучшении кода.
У 0.1.0-1 перехожу при каких-то серьезных добавлениях в систему, и т.п.
До 1.0.0 программы у меня с такой нумерацией еще не доживали :)

pacify ★★★★★
()
Ответ на: комментарий от shty

Подтвердить, что я логично распарсил написанное там. Просто мне один человек стал впаривать, что пофиг, что у меня все меняется, мажорную версию можно менять только когда все уже работает, а так она должна быть 0.

Zhbert ★★★★★
() автор топика
Ответ на: комментарий от anonymous_sapiens

Это самая первая версия же =) И генточка моя прекрасная, которая в тот момент была. Авесомчик, Ъ-тема гтк и т.д.

Zhbert ★★★★★
() автор топика

Искусство программирования для Unix , Эрик C. Реймонд, 2005

стр 478, раздел 19.2.2 «Хорошая практика наименования проектов и архивов»

anonymous
()

Из собсвенной практики.
В зависимости от модели разработки/релизов.

Если ты используешь простую модель разработки, тоесть существует «транк» и переодически делаешь срезы называя из «версия такаято», то имеет смысл использовать двухиндексную нумерацию, т.е. 0.2->0.4->1.1

Если немного расширить модель релизов в том аспекте что ты собираешься поддерживать несколько «срезов транка» одновременно, то тут соответственно и выплывает необходимость третьего индекса - т.н. патчлевел. Т.е. по факту 0.2.1 ничем не отличается от 0.2.12365123, за исключением того что было исправлено 12365122 багов.


Касательно двухиндексной нумерации... в даном случае имеет смысл менять мажорную версию только если что-то весьма существенно изменилось(описаная тобой ситуация переписывания всего вполне подходит). В то время как минормая версия миняетсе по мере накопления фичей(в один релиз входит несколько фичей как правило).

Jetty ★★★★★
()

Кстати, а че такой стремный интерфейс ? :)
И орфографические ошибки в новости поправь, а то нихарашо как-то

Jetty ★★★★★
()

A.B.C.D, где
A - major
B - minor
C - bugfix
D - build/revision/etc.

JackyTreehorn
()
Ответ на: комментарий от Zhbert

Подтвердить, что я логично распарсил написанное там. Просто мне один человек стал впаривать, что пофиг, что у меня все меняется, мажорную версию можно менять только когда все уже работает, а так она должна быть 0.

так положи на него, он тебе кто - прокурор «щитоле»? как чувствуешь что накопилось - меняй мажор, иначе минор, всё

shty ★★★★★
()

Номер билда для опенсорса вообще смысла не имеет.

Я свои поделия обзываю как А.Б.В, где А увеличивается при тектонических изменениях, Б — просто при изменении функционала, В — при багфикс-релизах. Впрочем, я этой нумерологии не всегда следую. :)

А вообще, какая разница как нумеровать (если не доводить до абсурда, конечно)?

Relan ★★★★★
()
Ответ на: комментарий от Relan

Номер билда для опенсорса вообще смысла не имеет.

лапша на уши пролилась дождём

приходит к тебе клиент и говорит что у него что-то отваливается, какой таг/ветку с репозитория ты себе будешь вытягивать? а так спросил версию и вытащил то что надо - profit налицо

shty ★★★★★
()

Подобная схема годится только для внутренней нумерации. Цифры C и D пользователю ничего не говорят. Для внешней нумерации лучше использовать, в зависимости от схемы разработки, двух- (major и minor, патчи багов для minor входят в minor+1 вместе с новыми фичами) или трех- (major, minor, patchlevel, баги чинят в patchlevel+1, новые фичи входят в minor+1) уровневую систему.

redgremlin ★★★★★
()
Ответ на: комментарий от shty

>приходит к тебе клиент и говорит что у него что-то отваливается, какой таг/ветку с репозитория ты себе будешь вытягивать?

git checkout $clientversion.

redgremlin ★★★★★
()

мажорным оно не будет, если ты не напишешь принципиально новую фичу, а лучше несколько
пользователю не важно что изменилось внутри
а еще ему не важно номер версии
впрочем как и тебя ругать никто не станет из-за того что ты ее назовешь 0.1.1, т.к. nobody cares :)

yltsrc
()
Ответ на: комментарий от redgremlin

>приходит к тебе клиент и говорит что у него что-то отваливается, какой таг/ветку с репозитория ты себе будешь вытягивать?

git checkout $clientversion.

clientversion - это что, откуда оно берётся?

shty ★★★★★
()

http://s011.radikal.ru/i315/1012/ea/53dab4362c15.png

Номер версии - это очень-очень важная тема. Особенно для такого серьезного и популярного продукта.

Обязательно держи нас в курсе событий! И напиши подробный отчет с картинками на Хабрахабр. Уверен, это будет интересно, умно и содержательно, как это у тебя обычно и бывает.

anonymous
()
Ответ на: комментарий от shty

> приходит к тебе клиент и говорит что у него что-то отваливается, какой таг/ветку с репозитория ты себе будешь вытягивать? а так спросил версию и вытащил то что надо - profit налицо

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

Relan ★★★★★
()
Ответ на: комментарий от Relan

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

1. далеко не все клиенты занимаются сборкой софтин, им надо чтобы работало
2. «номер ревизии» == «идентификатор сборки» и никаких проблем, по крайней мере мне так проще

shty ★★★★★
()
Ответ на: комментарий от shty

>clientversion - это что, откуда оно берётся?

Номер публичной версии. 1.2, к примеру, или 1.2.3

redgremlin ★★★★★
()
Ответ на: комментарий от shty

>2. «номер ревизии» == «идентификатор сборки» и никаких проблем, по крайней мере мне так проще

А пользователю не проще. Он не знает, чем отличается 1.0.0.1000 от 1.0.0.2000 - то ли вы туда уже новую ОС впихнули, то ли два раза с бейсика на ассемблер и обратно переписали, то ли просто в камментах друг другу в любви признавались. А вот когда пользователь на официальном сайте видит три версии - 2.0 alpha 2, 1.2.0 и 1.1.3, то он примерно представляет, чем эти версии отличаются.

redgremlin ★★★★★
()
Ответ на: комментарий от redgremlin

>2. «номер ревизии» == «идентификатор сборки» и никаких проблем, по крайней мере мне так проще

А пользователю не проще.

а пользователю пофиг дожно быть, он мне говорит номер версии, а уже я разбираюсь

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

shty ★★★★★
()
Ответ на: комментарий от Zhbert

>мне интересно как правильно

правильного ответа не существует. можно только холиварить)

annulen ★★★★★
()

Вот если разрабатываешь библиотеку, то правила более-менее определенные: меняешь ABI - повышаешь минорную (при этом для повышения минорной не обязательно менять ABI:), меняешь API - повышаешь мажорную

annulen ★★★★★
()
Ответ на: комментарий от shty

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

Т.е. это не просто пользователи, а активные участники процесса разработки. Т.е. это нумерация внутренняя, для разработки, и моему посту http://www.linux.org.ru/jump-message.jsp?msgid=6274969&cid=6275234 это не противоречит.

redgremlin ★★★★★
()
Ответ на: комментарий от shty

>«номер ревизии» == «идентификатор сборки» и никаких проблем, по крайней мере мне так проще

а если гит? по хэшу не видно, какая версия новее)

annulen ★★★★★
()
Ответ на: комментарий от annulen

>«номер ревизии» == «идентификатор сборки» и никаких проблем, по крайней мере мне так проще

а если гит? по хэшу не видно, какая версия новее)

эм, я вообще-то mercurial пользуюсь, а для указания номера версии/билда есть комментарий :)

shty ★★★★★
()
Ответ на: комментарий от redgremlin

Т.е. это не просто пользователи, а активные участники процесса разработки. Т.е. это нумерация внутренняя, для разработки

да обычные то пользователи, просто у них часто меняются вводные

у них свои эксплуатационщики, они говорят что для них сработало лучше, непосредственно к разработке это никакого отношения не имеет, так что это совсем не внутренняя нумерация

shty ★★★★★
()
Ответ на: комментарий от annulen

тогда уж тэг. А тэг надо называть по правилам, о чем и спрашивает ОП

и что, будет 100500 тэгов, нафиг? особенно, с учётом того что до следующего года доживут 2-3 (вот они и станут тэгами, если нужно)

shty ★★★★★
()
Ответ на: комментарий от shty

>и что, будет 100500 тэгов, нафиг?

нуачо, не тянут же. это же не svn-тэги все-таки)

annulen ★★★★★
()

В общем, понял, что вроде как я верно мыслил. Так что так и оставлю.

Zhbert ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.