А возможна ли глобальная унификация нумерации версий программного обеспечения?

Нет

Ну, нет так нет.

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

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

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

Нормальные, это которые штрих-код на глаз читают и сразу в уме парсят?

А как обозначить мажорные минорные версии? Так-то в репозиториях на новейших версиях обычно именно дату ставят.

Нормальные, это которые штрих-код на глаз читают и сразу в уме парсят?

Нет, это не нормальные.

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

Собственно дума родилась от темы с ClipIt. Здесь

Нет.

как обозначить мажорные минорные версии?

Никак. Зачем это во внешнем мире? Это ж сугубо внутренние дела разработчиков. Тем более, что мажор-минор тоже ещё трактуется каждой контрой по-своему.

Кстати, еще и с Dosbox было похожее приключение когда-то. Оно куда ни плюнь - везде 0.74. А на деле совершенно разный продукт. И нигде никак это не узнаешь, пока в исходник не посмотришь.

Люто возражаю.

Зачем это во внешнем мире? Это ж сугубо внутренние дела разработчиков.

Вот теперь сразу видно теоретика. Про штабильные и штабильно интирпрайсные говорить не буду ибо чистые руки и горячее сердце не дадут поверить. Но, вот такой примерчик - вышло ядро версии 10 которое сломало abi версии 9. Как быть в этой ситуации всем, у кого нет ресурсов перейти на 10? При том, что разработчики ядра вполне себе обладают ресурсами бэкпортировать критичные патчи реализации в версию 9. По твоей логике, следующий патч в 9, должен быть 11.

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

Думаю правильно было бы задать вопрос в теме в стиле - «Кто как видит правильное обозначение версий и почему именно так?»

ну, можно же нумеровать version.date, где
version = натуральное число, номер версии, обозначающий новый продукт, несовместимый со старым,
date = дата последнего патча в эту версию
в твоём примере:

• 9.date1
• 10.date2
• 9.date3

а вот версии, состоящие из нескольких (3 и более) чисел через точки и минусы - это ненужное усложнение

Вот теперь сразу видно теоретика.

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

вот такой примерчик - вышло ядро версии 10 которое сломало abi версии 9. Как быть в этой ситуации всем, у кого нет ресурсов перейти на 10? При том, что разработчики ядра вполне себе обладают ресурсами бэкпортировать критичные патчи реализации в версию 9.

Вот контр-примерчик: вышло ядро 51.01. А ядро 45.06 всё еще в поддержке и в него можно бэкпортировать. Тогда выходит ядро 45.06.001. (Числа условные - третья группа цифр(?) как-то должна передать мысль о бэкпортированой функциональности в старое ядро).

Пока объективно - никакой убедительности.
Скорее всего субъективно - никто не будет ломать свои готовые рельсы.

Теоретически же можно принять стандарт для версионирования ПО единый для всех отличный от семантического?

ГОСТ Р 2.105-2019 устанавливает общие требования к выполнению текстовых документов.
На его основе можно (но ненужно) забюрократизировать любые стандарты версионирования.

Проклятая бессонница )

Первая группа - вместо Unix Epoch, считать от 1843 года, как года создания первой программы.

Вторая группа - номер недели года. (это фиксация оригинального продукта)

Третья группа - модификации оригинального продукта, тут уж кто во что горазд.

Получается на сегодня что-то вроде 177.13 == оригинальный программный продукт (любой). а, допустим, 177.13.arch077 == с заплатками от ArchLinux.

)))

И ваши досужие домыслы не испортят моего художественного вымысла )

Я почти согласен.

Но бывают исключения и нужен как минимум четвёртый ряд.

Ну например. Есть версии программы как: фри, демо, про, …

Есть версии программы как: фри, демо, про, …
177.13.arch077(d/p/f)
177.13.arch077d
177.13.arch077p
177.13.arch077f

Третий ряд на любое извращение. Согласен с ТС полностью. Тогда бюрократия станет виднее, поэтому никто не будет принимать и следовать этим стандартам.
Я возможно сделаю такое изменение в своей политике нумерации версий.

Возможно, если отказаться от идеи повышения версии. Т.е. что 1.0 - древнее, чем 2.0. В качестве версии использовать GUID, а дату сборки - да кому она нужна? Главное - знать, что fe8c2204-4555-4266-a54d-a62234d1f2ed - глючная, а 86488999-b637-4ee5-bd72-932a481a315d - стабильная

Версия 45 осталась таковой, чуть реализация сменилась.

Но ты мне не верь, а проставь альтернативные версии ядру, гит то есть. А кейс не самый сложный.

а дату сборки - да кому она нужна?

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

date = дата последнего патча в эту версию

А если в день сделали две сборки ?

Забыл тред закрыть, в итоге туда всякого тупняка понаписали.

date = дата последнего патча в эту версию

А если в день сделали две сборки ?

да что ж вы как рабы на галерах?
не нужно так сильно перерабатывать

ну ок, дата будет выглядеть так: YYYY-MM-DD-HH-MI-SS-FFFFFF
причём вы указываете столько полей в дате, сколько требуется
у кого-то сборки выходят раз в год, и будет 9.2020
у кого-то каждый день, и будет 9.2020-03-28
а если в этот день выпустили вторую сборку в 11 часов, то следующая будет 9.2020-03-28-11
благодаря лексикографической сортировке, эти версии расположатся в нужном порядке (в порядке создания сборок):
9.2020
9.2020-03-28
9.2020-03-28-11
ну, или без минусов, для однообразия:
9.2020
9.20200328
9.2020032811

Нет

А в чём смысл? От того что какая-то yoba собрана в тот же день что и chrome она не станет такой же плохой хорошей как chrome. Т.о. версия ни о чём говорить не будет, наоборот введёт в заблуждение, что некий продукт соотносим с другим по зрелости.

Например, смысл в более прозрачной и очевидной процедуре включения продуктов в наборы продуктов (дистрибутивы) и их поддержки в них.

Само название же продукта - это имя собственное и, следовательно, может называться как угодно. «Chromium80», «Windows10», «PostgreSQL-9», «ClipIt★SuperPuper★Sparta★1000»

------------
Моя очередь вопроса: а какой смысл для пользователя ориентироваться в версиях 0.74, 80.0.3987.149, 1.4.4, 74.0 ?

Так ночные архивы с Хромиумом и так в названии содержат таймстемп. Привет!

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

Тогда уже сразу https://tools.ietf.org/html/rfc4122

А если v1.0.1 была собрана завтра, а v2.0.0 будет собрана вчера?

это ж не дата сборки, а дата коммита кода

ну нужно взять все версии за эту дату и перебирать все подряд, пока не перестанет сегфолтиться :)

а как тогда быстро, без вникания, понять какая из версий более свежая?

А зачем вам это нужно? Просто к каждой версии будут идти свои системные требования

гуид - это человеко-не-читаемая бяка, причём чересчур раздутого размера

Безусловно. Но ТС хотел глобальную унификацию, а не нормальную, удобную для человеков, глобальную унификацию

Напомнило https://imgs.xkcd.com/comics/standards.png

Так ночные архивы с Хромиумом и так в названии содержат таймстемп. Привет!

Виноват, не нашел. Void в своём template хочет вот такое:

pkgname=chromium
version=80.0.3987.149

https://commondatastorage.googleapis.com/chromium-browser-official/${pkgname}-${version}.tar.xz

----------------------------

Посидел посравнивал Chromium в Arch и в Void.

Там 80.0.3987.149, и там 80.0.3987.149
Казалось бы - пользуюсь абсолютно одним и тем же продуктом.

Но вот библиотеки, которые есть в ldd chromium в Void, но которых нет в Arch:

	libcelt
	libEGL
	libevent
	libGLdispatch
	libGL
	libGLX
	libOpenCL
	librtmp
	libssl
	libuuid

А вот, наоборот, библиотеки с которыми собирается в Arch, но нет в сборке в Void

        libaom
	libblueray
	libcom_err
	libgcrypt
	libgomp
	libgpg
	libgsm
	libgssapi
	libk5crypto
	libkeyutils
	libkrb5
	libkrb5support
	liblz4
	libmfx
	libminizip
	libopencore-amrnb
	libopencore-amrwb
	libopenjp2
	libsoxr
	libssh
	libsystemd

По заплаткам - у Void 15 штук *.patch, у Arch 11 штук *.patch. И ни одного между ними общего, насколько вижу. (у Void еще отдельная кучка заплаток для i686 и musl)

Явно же разные продукты с точки зрения пользователя.

Вполне логично по-моему выглядело бы 177.12.void-x86-64-libc-15 и 177.12.arch-11, например. И таймштампов не надо - оно уже есть, и явно видно, что продукты с разными модификациями.

а как тогда быстро, без вникания, понять какая из версий более свежая?

А зачем вам это нужно? Просто к каждой версии будут идти свои системные требования

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

зачем тогда вообще нужен процесс смены версий?

Вот я и не знаю.

В убунте уже нормально все, максимально человекопонятно.

А как обозначить мажорные минорные версии? Так-то в репозиториях на новейших версиях обычно именно дату ставят.

Нынешние версии Хрома и Фаерфокса мажорными не являются. Серьёзные изменения у них бывают раз в 20-30 версий. С тем же успехом могли бы заменить версии на «год.месяц[.число[.минорная_версия]]». Или «год.неделя[.минорная_версия]». Как в Убунту — «год.месяц».

С минусами и точками читаемее.

Невозможно, потому что не нужно

там же децентрализованная разработка. Никто не шарит патчи между собой, разве что на уровне «скопипащу у друга»

Всё-таки, наверное, хочу подвести черту под этой фантазией.

1. SemVer (Семантическое Версионирование) предназначено для «для версионирования продукта, предоставляющего внешний api.» (это цитата).

2. Если вы выпускаете продукт для конечных пользователей, то нет никакой причины не использовать другие способы версионирования.

3. Наиболее логичным и понятным для человека мне кажется способ декларирования версии привязанный к времени публикации.

Из наиболее объективных временных характеристик - обращение Земли вокруг Солнца (год), и обращение Земли вокруг своей оси (сутки). Месяцы и недели это уже слишком абстрактные понятия, как и точка отсчёта количества лет. Поэтому за точку отсчёта предлагается взять 1843 год от Р.Х., как общепринятый год создания первой программы для вычислительной машины. Можно назвать это НЭПО (начало эпохи программного обеспечения).

Предлагается формат X:Y[:Z], где X - год от НЭПО, Y - сутки года, Z - необязательная дополнительная составляющая для описания деталей реализации продукта. В качестве разделителя групп предлагается двоеточие для отличия от SemVer.

Вроде теперь всё, кончилась фантазия на эту тему.