LINUX.ORG.RU

Формат версий


0

1

Посоветуйте формат номера версии ПО, который
1) Универсальный (совместим с разными моделями разработки, etc.)
2) Максимально короткий. Максимально цифровой.
3) Учитывает ветвления, слияние...* То есть совместимый с современными VCS типа git, hg.
4) Сравнимые версии** должны сравниваться пакетными менеджерами. То есть x1.y1.z1... > x2.y2.z2... при x1>x2 или (x1=x2 и y1>y2 или (...)), то есть лексикографически, но внутри каждого поля (x,y,z,..) как целые числа***.
5) Уникальный****. Точность до «коммита» (в смысле git, т.е. элементарного функционально законченного изменения). Но: не требуется особое выделение релизов, тестовых версий, etc*****. То есть номер версии инкрементируется всегда одинаково независимо от масштаба изменения.

P.S. Просьба не обсуждать указанные требования. Мне нужна помощь только в выборе подходящего формата нумераций.



_____________
* Таким образом, простой линейный порядок версий 1,2,3... (как издания книги) не подходят.
** Например, в одной ветке. Вообще же говоря разные версии одного ПО не обязаны быть сравнимыми (опять же, например, разные ветви разработки).
*** Таким образом, git'овский sha1 или т.п. идентификаторы не подходят.
**** Таким образом, формат версии в виде текущей даты (YYYY.MM.DD) не годится. Он не подходит и по п.3.
***** Ибо это, во-первых, субъективно, а во-вторых, указание стабильности/тестовости/... той или версии можно сделать в документации или на офсайте.



Последнее исправление: toady2 (всего исправлений: 3)

>Таким образом, git'овский sha1 или т.п. идентификаторы не подходят.

а git-овские метки не подходят?

lazyklimm ★★★★★
()

Посмотри методику нумерации ревизий в CVS. Там, помнится, как раз что-то такое и сделано.

ynn
()
Ответ на: комментарий от lazyklimm

а git-овские метки не подходят?

Ну, грубо говоря, формат этой метки я и спрашиваю. Именованные названия (vasya, petya) не подходят по п.2,3,4.

toady2
() автор топика

> Просьба не обсуждать указанные требования. Мне нужна помощь только в выборе подходящего формата нумераций.

Такого формата не существует (сравнение на > всё портит). Но это не проблема, потому что твои ребования не имеют смысла.

tailgunner ★★★★★
()

У нас принят такой формат:
1 число: кардинальная переработка.
2 число: новый функционал.
3 число: фиксы.
Заказчику идёт только master/default, где хватает этих 3-х цифр. После этих 3-х цифр можно через дефис писать любую «хрень», означающую, что версия не годится для заказчика.
Походит ли Вам такое - хз...

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

Ну зачем же так категорично? В нулевом приближении можно что-то типа такого: инициальный коммит имеет версию «1». Следующий коммит — «2». И т. д. В момент ветвления одна ветвь получает индекс «a», вторая «b» и т. д. Далее по рекурсии.

Графически:

   1
   |
   2
   |
 --3---------
/     \      \
3a.1   3b.1   4
|      |      |
3a.2   3b.2   5--
|             |  \
3a.3          6   5a.1
|             |   |

  ...
Только вот проблема со слиянием.

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

Ну зачем же так категорично?

В моем утверждении категоричности не больше, чем в «Волга впадает в Каспийское море». Категоричным (но тоже верным) было бы утверждение «тебе это не нужно».

Только вот проблема со слиянием.

Проблема в том, что в разных DVCS-репозиториях цифры повторятся. И эта проблема неразрешима (если ты не Ларри Маквой).

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

Прочитав последний комментарий, понял - что требуется.
Если при каждом ветвлении добавлять ещё одну точку, то разрешима.

backbone ★★★★★
()

Версия нужна только у *релиза* ПО. Поэтому твои требования несколько бестолковые.

На прошлой работе был проект, который релизился по несколько раз на день. Формат версий был таков: YYMMDDhhmm.

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

> Если при каждом ветвлении добавлять ещё одну точку, то разрешима.

Неразрешима всё равно. Недаром практически все DVCS пользуются хэшами для идентификации версий. А если ввести хэш как компонент версии, то отавлится возможности сравнения на >.

А вообще, baverman прав - версии нужны только для релизов, которые можно делать из отдельного репозитория. В одном репозитории проблема уникальности версий решается тривиально.

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

> версии нужны только для релизов

Полностью согласен!
Но автору надо иначе же... вроде...

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

> 1 число: кардинальная переработка. 2 число: новый функционал. 3 число: фиксы.

Ну, опять же — присутствует субъективность. Вот, скажем... эм... изменение касается *замены* одной фичи другой (т.е. старая убралась, а вместо неё добавилась новая, направленная на то же, но реализованная иначе и выглядящая иначе); при этом пришлось что-то коренное изменить в «ядре» программы. Какое число менять?

Заказчику идёт только master/default


А вдруг одинаково полезны оказались несколько веток. Продолжим тот же пример: одна ветвь пошла со старой фичей, а другая с заменённой. Одни пользователи любят старую, другие новые. Мы хотим угодить всем и релизим всё.

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

> А вдруг одинаково полезны оказались несколько веток. Продолжим тот же пример: одна ветвь пошла со старой фичей, а другая с заменённой. Одни пользователи любят старую, другие новые. Мы хотим угодить всем и релизим всё.

Это значит, что у вас фактически несколько продуктов с разными номерами версий. В любом случае, сравнение на < между ветками уже бессмысленно.

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

Версия нужна только у *релиза* ПО.

Не согласен. Пусть мой проект лежит открытым на github, в нём много веток (напр. одна ветка c GUI под qt, другая под gtk, а третья под консоль). Один пользователь прочёл, что версия x.y.z из нужной ему ветки (= с требуемым функционалом и пр.) стабильна и он её качает. Он может это делать пакетным менеджером, который проверяет наличие новой версии (сравнивая их лексикогрфически в целом и как числа внутри каждого поля). Ну, надеюсь, понятно, что я имею в виду.

toady2
() автор топика
Ответ на: комментарий от tailgunner

Проблема в том, что в разных DVCS-репозиториях цифры повторятся.

Будем пока считать, что репозиторий централизованный. А каждый разработчик используется внутренний формат (sha1, например). При заливке на центр там автоматически назначаются метки в соответствии с выбранным форматом нумераций.

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

> Ну, опять же — присутствует субъективность. Вот, скажем... эм... изменение касается *замены* одной фичи другой (т.е. старая убралась, а вместо неё добавилась новая, направленная на то же, но реализованная иначе и выглядящая иначе); при этом пришлось что-то коренное изменить в «ядре» программы. Какое число менять?

Думается, что второе. Но, в Вашей схеме уже не сработает. Придётся сначала делать слияние кучи веток, если не ошибаюсь.

> А вдруг одинаково полезны оказались несколько веток. Продолжим тот же пример: одна ветвь пошла со старой фичей, а другая с заменённой. Одни пользователи любят старую, другие новые. Мы хотим угодить всем и релизим всё.

На этот счёт тоже задумывался. Если заказчиков ограниченное число, то можно менять имя проекта вроде project_zakazchickA-x.y.z, project_zakazchikB-x.y.z... И периодически в них переносить изменения из master/default-ветки. Если заказчиков много, то фиг знает...

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

напр. одна ветка c GUI под qt, другая под gtk, а третья под консоль

И что мы имеем? Три *разных* продукта со своей нумерацией. Не вижу проблем.

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

ТС, делай просто project-branch-any_version_format_you_like. Нумерация для каждой ветки, естественно, независимая. Уберет кучу гимора, которую пытаешься здесь разгрести.

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

> При заливке на центр там автоматически назначаются метки в соответствии с выбранным форматом нумераций.

Тогда получается, что версии назначаются в едином репозитории, и проблема тривиальна (а если и нетривиальна, то давно решена - в CVS, например). Картинка, которую рисовал backbone, очень похожа на правду.

Но это случай одного продукта, а не нескольких, замаскированных под ветки.

tailgunner ★★★★★
()

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

toady2
() автор топика
Ответ на: комментарий от baverman

Да, наверное, придётся на этом и остановится. Просто ветки могут быть с крайне незначительными изменениями и их может быть много (ой, кстати, а как у linux-kernel с версиями дело; там же, наверное, как раз мой случай).

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

ой, кстати, а как у linux-kernel с версиями дело

Грубо говоря, версии есть только у основной ветки. А на них уже «накладываются» сторонние патчи и делаются альтернативные пакеты. Совсем не твой случай.

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

> Очень разумный документ. Хотя 3-х цифр маловато :/

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

И непонятно, что делать, когда API нужно сломать второй раз.

Первую цифру увеличить.

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

> Двух зачастую хватит

А мне иногда нужно 4

И непонятно, что делать, когда API нужно сломать второй раз.

Первую цифру увеличить.

А дальше? Понятно, когда первая цифра 0 - всё считается нестабильным и ломаным. А когда первая цифра 2 - тоже всё считать нестабильным?

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

> Понятно, когда первая цифра 0 - всё считается нестабильным и ломаным. А когда первая цифра 2 - тоже всё считать нестабильным?

Ну там же написано. В рамках одной старшей версии сохраняется обратная совместимость. Нужна стабильность - не обновляй 2.x на 3.x.

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

>> Понятно, когда первая цифра 0 - всё считается нестабильным и ломаным. А когда первая цифра 2 - тоже всё считать нестабильным?

Ну там же написано. В рамках одной старшей версии сохраняется обратная совместимость.

Наверное, я хреново объясняю. Итак, вторая попытка: во время разработки API постоянно ломается, и гарантий совместимости нет - для таких версий предлагается использовать номер версии 0. ОК, всё понятно. Теперь выпущена версия 1.0, она начинает жить своей тихой жизнью, но пора разрабатывать следующую, несовместимую по API с 1.x.x. Какой номер должна иметь эта версия на время разработки? Версия 1.x.x была 0.x.x

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

> Теперь выпущена версия 1.0, она начинает жить своей тихой жизнью, но пора разрабатывать следующую, несовместимую по API с 1.x.x. Какой номер должна иметь эта версия на время разработки? Версия 1.x.x была 0.x.x

Если хочется делать релизы недописанной новой версии и при этом продолжать ломать апи, то semver в пролёте. По правилам, пришлось бы старшую версию менять с каждым недорелизом. Я вижу два варианта. Первый: таки собрать все изменения апи в релизе 2.0.0, перед которым можно выпустить кучу alpha, beta и rc. Второй: начать новый проект и нумеровать с нуля, коли уж такая масштабная революция.

Первые три вопроса тамошнего фака связаны с этой проблемой.

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

> Если хочется делать релизы недописанной новой версии и при этом продолжать ломать апи, то semver в пролёте.

Использование версии 0 это позволяет.

Первые три вопроса тамошнего фака связаны с этой проблемой.

Мой вопрос - это 3 пункт FAQ. Как раз тот, который состоит из невразумительного мычания про «incurred cost».

Отчасти поэтому хочется 4 цифры.

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

> 3 пункт FAQ

Аналогичный вопрос. Есть один небольшой подпроект-библиотека, который используется множеством других. В силу непреодолимых обстоятельств в нём постоянно меняется API.

Следуя Semver (кстати спасибо const86 за ссылку) сейчас была бы версия 42.0.0.

По какому принципу лучше разбить первую цифру на две? Не нашёл каких-то общепринятых правил, хотя может мало гуглил.

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

Ещё, немного подумав, конкретно в моём случае 2-ая цифра Semver теряет смысл, т.к. по сути, введение нового функционала всегда влечёт поломку API. В итоге опять получится 3 цифры.

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

> Есть один небольшой подпроект-библиотека, который используется множеством других. В силу непреодолимых обстоятельств в нём постоянно меняется API.

Если постоянно, и стабильного API ни разу не было, то это 0.x.x. А хорошей схемы для выдачи номеров релизов при периодической смене API нет (я вообще могу вспомнить только раннюю схему нумерации Linux - вторая четная цифра означала релиз из стабильной линии).

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

> Тогда пусть будет 0.x.

Эта библиотека тогда всегда будет 0.x, пока от неё вообще не избавимся, а случится такое вряд ли. Хотя, может это и правильно. Заодно камень в огород, как разрабатывать софт нельзя.

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

> Если постоянно, и стабильного API ни разу не было, то это 0.x.x. А хорошей схемы для выдачи номеров релизов при периодической смене API нет (я вообще могу вспомнить только раннюю схему нумерации Linux - вторая четная цифра означала релиз из стабильной линии).

Пожалуй, что так. Проблема в организации системы, для которой написана библиотека. Будет вечная 0.x.x и тут ничего не поделаешь...
Пример с [не]чётной нумерацией версий ядра вылетел из головы!

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