Здравствуйте, ·, Вы писали:

f>>

Заслуга semver теперь в том, что на него пытаются натянуть всё подряд, на той самой волне хайпа. В том числе и нюгет ушел в несознанку.

·>Так натягивается же.
Я показал где он не подходит. Но его всё равно упорно натягивают.

f>> Повсеместное форсирование semver — не учитывает главного, — а именно, потребностей разработчика, и сложности (или простоты) софта. Или вообще назначения.
·>Учитывает достаточно чтобы покрыть и сложный (не путаем с переусложнённым), и простой софт.
Технологии не должны следовать правилу 80/20 или good enough. Технологии должны давать так много, как только могут. В противном случае, они быстро морально устаревают.

f>> >Ключевое слово тут "традиционно". Нет никакой рациональной необходимости в этом зоопарке. Поэтому и предлагается стандарт.
f>> Это не стандарт, и даже не рекомендация.
·>Спецификация, набор правил, соглашение. Какая разница?
Разница только в том, что ничем не обоснованные ограничения semver2 энфорсят куда не попадя.
А ответственность (семантичность) формируемых автором версий — лежит на его плечах, и от схемы версионирования никак не зависит.
Таким образом автор всё равно должен декларировать, какой семантики он собирается придерживаться.

f>> В мире пишут люди с лева направо и справа налево, почему бы не писать всем справа на лево? Ну что бы по стандарту?
·>Плохая аналогия. Не надо путать культурные ценности и инженерную дисциплину.
Отличная аналогия, в программировании — есть свои культурные ценности.

f>> Нет никакой реальной необходимости как либо ограничивать разработчиков в выборе схемы версионирования, тем более что в основном все популярные схемы — основаны на последовательности идентификаторов, с индикацией важности изменения определяемой позицией каждого идентификатора. 1.0.2d — точно такая же версия.
·>Зачем у тебя в розетке 220 вольт? Ведь нет никакой необходимости, и 22, и 2200 — точно такие же вольты.
О как. А как же так, что ещё используется 110? "Ведь нет никакой необходимости."

f>> Исходный код никому ничего не обязан, и идентичные бинарники не генерируются при тех же равных и так. Кроме того артефакты могут зависеть от установленного софта и его обновлений. Поэтому "reproducible build" гарантировать всё равно никто не сможет, особенно с течением времени. Легче все артефакты хранить, в том числе и с .pdb.
·>Бардак, что ещё сказать... У нас нет "установленного софта". Точная версия jdk, python, и прочего явно указана в исходном коде.
Это не бардак, а объективная реальность. Не весь софт ставится side-by-side. А "reproducible" будет ограничена только тем, что выданы будут похожие бинарники. Максимально близкие — да, но не более.

f>> Кроме того библиотека версии A.B.C может поставляться в 3-х упаковках: с UTF8 строками, с UTF16 строками и UTF32. Как автору библиотеки — тебе может быть фиолетово, для тебя — это всё есть A.B.C. Для потребителей артефактов — это 3 разных версии, с несовместимым ABI.
·>Для потребителей это три разных библиотеки. Потребитель скорее всего будет использовать одну из них (или так же делать три упаковки) и отслеживать изменения именно "A.B.C".
Именно. И если автор публикует их все 3 сразу — они должны идентифицироваться каким-то образом.

f>> ·>По-моему стандарт достаточно универсален, поэтому можно вписать всё.
f>> За рамками A (A.B.C) — ничего универсального нет. Любой постфикс делает версию 'prerelease'. Префиксы вдобавок ограничены странными правилами. Невозможно указать postrelease.
·>А какой смысл вложен в этот postrelease? Почему нельзя сделать A.B.(C+1)?
Потому что A.B.(C+1) уже опубликован.

f>> Вообще в интернете если поискать есть полно критики semver.
·>Я нашел два:
·>1. Effort is required to do the right thing
·>2. This will be an ongoing effort until downstream projects adopt Semantic Versioning.
·>Хех...
В гугле забанили? Ну вот одно из более-менее внятных личных мнений: https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e . https://github.com/jashkenas/backbone/issues/2888#issuecomment-29076249 . http://sentimentalversioning.org/ .
В конце концов есть и historical-based схемы, которые так же используются (хотя они и не будут так удобны).

f>> Build metadata не являются частью версии в semver2 и из сравнения исключаются.
·>И правильно что исключаются. Сравнение нужно для чего? Для того, чтобы принять решение — нужно ли обновление версии или нет и оценить сложность. Я вот помню уже попадал на такую граблю, когда выбирал последний релиз смотря на строки типа "15.28.24.64.4229", "15.28.24.64.4532", "15.28.24.86.4532" .
Каким образом тогда 1.0.0+x86 и 1.0.0+x64 будут различимы? Вообще архитектура — это так же часть версии артефакта, однако никакого предшествования тут быть не может, и они естественно должны обрабатываться специальным образом. (Т.е. выбираем правильный пакет, в зависимости от таргета или рантайма).

f>> При этом очевидно что 64 и 86 — есть весьма разные билды, которые живут параллельно -> следовательно платформу невозможно положить в build metadata. Что касатеся очевидности, то предшествование версий обеспечивается принятой схемой версионирования, и некоторые из них — очевидны. Другие нет. При этом семантика схемы — обеспечивается автором. На ручнике или с помощью тулзов. Поэтому кроме как говорить о возможной рекомендации — не приходится.
·>Но уж точно платформу нельзя класть в значимый номер версии.
Выше написал — не согалсен.

·>Понятно, конечно, что можно делать. Но это вовсе не значит, что так нужно делать.
Выше написал. То как это у Intel — по дурацки, я и не спорю. Вопрос лишь в том, что если им удобно именно так — отлично. Это называется схемой версионирования. Они имеют свою идентификацию по своим правилам. Вот и всё. Другое дело, что с этими версиями мало что сделаешь, т.к. они в разных плоскостях и реально ни один специально не написанный тулинг с этим правильно работать не будет.

f>> В случае с debian — это именно версия пакета. Т.к. этот пакет собирается особым образом, наносятя патчи, конфигурируются и прочие вещи. Это позволяет пушить изменения (исправления), в том числе и секьюрити фиксы, для библиотек, базовая версия которых к тому моменту — не изменилась. Вместе с тем, это не параллельное версионирование. Это больше похоже на бранч.
·>А когда прописываешь зависимости, ты же указываешь mono "4.0.3.20", а не "4.0.3.20+dfsg-1~xamarin2". Правильно понимаю?
В большинстве случаев да. Но ты волен прописать и полную версию.

f>> Ещё раз — semver пихать куда не попадя — не нужно.
f>> Для продуктов может быть достаточно A.B. Для библиотек A.B.C, мы всё равно все к этом привыкли.
·>Для маркетинга продуктов хоть "XYZ", но внутри должно быть A.B.C — чтобы сисадмины могли это в своих puppet/chef-скриптах писать и программисты легко интегрироваться.
Ввиду той самой "reproducible build" — софт один хрен должен ссылаться на конкретные версии. А апгрейдить зависимости — по требованию / предлагать. А для того, что бы ссылаться на любую версию (представимую ввиде строки) — вообще никакая схема версионирования не нужна. Ссылаться же на часть версии, и выбирать последнюю — это — уже соглашение и ответственность. Последствия и риски должен понимать прежде всего тот, кто ссылается не на конкретную версию, а на её часть.

f>> Для иных случаев — ровно то, что решит автор, если он чувствует в этом необходимость.
·>Извини, но софтостроение — инженерная дисциплина. Там не чувствовать надо, а рационально решать.
Что бы что-то рационально решить, сначала нужно иррационально почувствовать, предложить и внедрить. Софтостроение и "инжерная дисциплина" заканчиваются в университетах.

f>> Короче говоря — как только будете заниматься маппингом технологических версий на внешние, только лишь для того, что бы угодить тулзам, которые с другими схемами версий не работают — тогда станет всё понятно.
·>semver ничего о внешних (маркетинговых) версиях не говорит, хоть Lollipop, хоть Vista.
Зато semver много чего говорит о внутренних версиях, и вводит поняние prerelease. Кроме того тут вообще о "маркетинговых" версиях никто не говорил.

Здравствуйте, ·, Вы писали:

·>·> ubuntu и windows можно объяснить тем, что это не совсем версии продукта, а идентификаторы сборок: оригинальный номер продукта (mono 4.0.3.20) + номер и обёртки чтобы это положить в dep-package list.
·>Это отличается потому, что ты, собирая свой продукт, будешь добавлять зависимость mono версии "4.0.3.20", а не "4.0.3.20+dfsg-1~xamarin2", а дальше package manager сам разберётся что делать с этими +-~.
Нет. Собирая свой продукт, ты озаботишься, что бы он собирался с правильными зависмостями, и аггрегировал правильные зависимости, а сами зависимости брались из правильных репозиториев. Соответственно — "4.0.3.20+dfsg-1~xamarin2".
Здесь вообще-то нет единого общего решения, т.к. назначение — разное.
Я опять вынужден повториться, — спецификации, рекомендации и соглашения — согласуют разработчиков. Технологии и тулзы — помогают. Не наоборот.

PS: Debian — был пример того, каким беспомощным выглядит semver, если бы его пытались натянуть на это. Другие репозитории используют другие правила, однако туда semver тоже не влезет. Вместе с тем — все модные репозитории для разработчиков (nuget, npm) — гонятся за semver, из хороших побуждений, однако игнорируют тот факт, что это механизм дистрибуции. Т.е. изначально репозиторий не может вместить себе оригинальную авторскую версию (openssl 1.0.2d), затем — непонимание разных форм упаковок/назначения (исходники, бинарники, ...). Так рождаются пакеты somelib-platform-arch которых быть как бы и не должно быть. И таких точек вращения — может быть много, в том числе и те, о которых ты ничего не подозреваешь. Даже если конкретный менеджер пакетов или репозиторий имеет встроенную поддержку платформ и архитектур — какого черта версия пакета не должна этого отражать, т.е. например быть 1.3.0-win.x64 (и это релизная версия, пересечения с semver случайны)?

Здравствуйте, fddima, Вы писали:

f>>>

Заслуга semver теперь в том, что на него пытаются натянуть всё подряд, на той самой волне хайпа. В том числе и нюгет ушел в несознанку.

F>·>Так натягивается же.
F> Я показал где он не подходит. Но его всё равно упорно натягивают.
Ты показал где он не используется. Но это не означает, что его там невозможно использовать.

f>>> >Ключевое слово тут "традиционно". Нет никакой рациональной необходимости в этом зоопарке. Поэтому и предлагается стандарт.
f>>> Это не стандарт, и даже не рекомендация.
F>·>Спецификация, набор правил, соглашение. Какая разница?
F> Разница только в том, что ничем не обоснованные ограничения semver2 энфорсят куда не попадя.
F> А ответственность (семантичность) формируемых автором версий — лежит на его плечах, и от схемы версионирования никак не зависит.
Логично. Стандартная схема версирования же позволяет донести это до других, облегчить коммуникацию.

F> Таким образом автор всё равно должен декларировать, какой семантики он собирается придерживаться.
Самое разумное декларирование состоит из шести букв: "semver".

F>·>Плохая аналогия. Не надо путать культурные ценности и инженерную дисциплину.
F> Отличная аналогия, в программировании — есть свои культурные ценности.
Ф топку их, как и аршины с пядями, и дюймы бы туда же. Единственная их ценность — тормозить развитие отрасли.

F>·>Зачем у тебя в розетке 220 вольт? Ведь нет никакой необходимости, и 22, и 2200 — точно такие же вольты.
F> О как. А как же так, что ещё используется 110? "Ведь нет никакой необходимости."
Верно. Но, как я понимаю, в масштабах страны экономический эффект перехода с 110 к 220 в краткосрочной перспективе, скорее всего, будет отрицательный.

f>>> Исходный код никому ничего не обязан, и идентичные бинарники не генерируются при тех же равных и так. Кроме того артефакты могут зависеть от установленного софта и его обновлений. Поэтому "reproducible build" гарантировать всё равно никто не сможет, особенно с течением времени. Легче все артефакты хранить, в том числе и с .pdb.
F>·>Бардак, что ещё сказать... У нас нет "установленного софта". Точная версия jdk, python, и прочего явно указана в исходном коде.
F> Это не бардак, а объективная реальность. Не весь софт ставится side-by-side.
Это проблема софта, которую надо исправлять, а не необходимость.

F> А "reproducible" будет ограничена только тем, что выданы будут похожие бинарники. Максимально близкие — да, но не более.
Должны быть — с эквивалетным поведением, остальное — неважно.

F>·>Для потребителей это три разных библиотеки. Потребитель скорее всего будет использовать одну из них (или так же делать три упаковки) и отслеживать изменения именно "A.B.C".
F> Именно. И если автор публикует их все 3 сразу — они должны идентифицироваться каким-то образом.
Правильно, пусть идентифицируются — именем файла, названием артифакта, классификаторм, arch-тегом, любым другим способом, но не пихайте это в номер версии, номер версии это не место куда можно запихать имя соседской кошки. Иначе он становится бесмысленным, случайным набором символов.

f>>> ·>По-моему стандарт достаточно универсален, поэтому можно вписать всё.
f>>> За рамками A (A.B.C) — ничего универсального нет. Любой постфикс делает версию 'prerelease'. Префиксы вдобавок ограничены странными правилами. Невозможно указать postrelease.
F>·>А какой смысл вложен в этот postrelease? Почему нельзя сделать A.B.(C+1)?
F> Потому что A.B.(C+1) уже опубликован.
Пусть A.B.(C+n). Притом A.B.(C+n) должен включать все изменения A.B.(C+n-1), иначе ад и израиль.
Что этот postrelease значит-то? Когда, кому и зачем на него апдейтится?

f>>> Вообще в интернете если поискать есть полно критики semver.
F>·>Я нашел два:
F>·>1. Effort is required to do the right thing
F>·>2. This will be an ongoing effort until downstream projects adopt Semantic Versioning.
F>·>Хех...
F> В гугле забанили? Ну вот одно из более-менее внятных личных мнений: https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e .
F> http://sentimentalversioning.org/ .
Если ты не понял — это ирония и сарказм, ржут над "что решит автор, если он чувствует в этом необходимость".

F> https://github.com/jashkenas/backbone/issues/2888#issuecomment-29076249 .
Ну и? Иначе говоря "Effort is required to do the right thing", и, видимо, этот Effort не хотят делать, отпинываются как могут.

F> В конце концов есть и historical-based схемы, которые так же используются (хотя они и не будут так удобны).
Ф топку их.

F>·>И правильно что исключаются. Сравнение нужно для чего? Для того, чтобы принять решение — нужно ли обновление версии или нет и оценить сложность. Я вот помню уже попадал на такую граблю, когда выбирал последний релиз смотря на строки типа "15.28.24.64.4229", "15.28.24.64.4532", "15.28.24.86.4532" .
F> Каким образом тогда 1.0.0+x86 и 1.0.0+x64 будут различимы? Вообще архитектура — это так же часть версии артефакта, однако никакого предшествования тут быть не может, и они естественно должны обрабатываться специальным образом. (Т.е. выбираем правильный пакет, в зависимости от таргета или рантайма).
Это часть идентификатора артифакта, но не версии. Идентификатор артифакта — многомерный, не надо пихать всё в одно измерение.

F>·>Понятно, конечно, что можно делать. Но это вовсе не значит, что так нужно делать.
F> Выше написал. То как это у Intel — по дурацки, я и не спорю. Вопрос лишь в том, что если им удобно именно так — отлично. Это называется схемой версионирования. Они имеют свою идентификацию по своим правилам. Вот и всё. Другое дело, что с этими версиями мало что сделаешь, т.к. они в разных плоскостях и реально ни один специально не написанный тулинг с этим правильно работать не будет.
То что им "удобно" (а скорее всего это просто изобретение какого-нибудь идиота-менеджера, которого, надеюсь, уже уволили, но менять это сложно и не хотят тратить на это время-деньги), не означает что использование semver не будет удобнее.

F>·>А когда прописываешь зависимости, ты же указываешь mono "4.0.3.20", а не "4.0.3.20+dfsg-1~xamarin2". Правильно понимаю?
F> В большинстве случаев да. Но ты волен прописать и полную версию.
Но это, как мне кажется, не рекомендуется и используется только как workaround.

F>·>Для маркетинга продуктов хоть "XYZ", но внутри должно быть A.B.C — чтобы сисадмины могли это в своих puppet/chef-скриптах писать и программисты легко интегрироваться.
F> Ввиду той самой "reproducible build" — софт один хрен должен ссылаться на конкретные версии. А апгрейдить зависимости — по требованию / предлагать.
И как предлагать-то? Предлагать апдейт "15.28.24.64.4532" до "15.28.24.86.4532"?

F> А для того, что бы ссылаться на любую версию (представимую ввиде строки) — вообще никакая схема версионирования не нужна. Ссылаться же на часть версии, и выбирать последнюю — это — уже соглашение и ответственность. Последствия и риски должен понимать прежде всего тот, кто ссылается не на конкретную версию, а на её часть.
И на совести кто релизит конкретную версию.

f>>> Для иных случаев — ровно то, что решит автор, если он чувствует в этом необходимость.
F>·>Извини, но софтостроение — инженерная дисциплина. Там не чувствовать надо, а рационально решать.
F> Что бы что-то рационально решить, сначала нужно иррационально почувствовать, предложить и внедрить. Софтостроение и "инжерная дисциплина" заканчиваются в университетах.
Уже прочувстовали и предложили sevmer, осталось внедрять, зачем ходить по тем же граблям?

F> Зато semver много чего говорит о внутренних версиях, и вводит поняние prerelease. Кроме того тут вообще о "маркетинговых" версиях никто не говорил.
Клёво. И правильно делает.

Здравствуйте, fddima, Вы писали:

F> Так рождаются пакеты somelib-platform-arch которых быть как бы и не должно быть.
Почему? Ибо someapp-platform-archX будет зависеть именно от somelib-platform-archX разных версий. Не имеет смысл делать someapp for archX зависимой от somelib-platform-archY.

F> Даже если конкретный менеджер пакетов или репозиторий имеет встроенную поддержку платформ и архитектур — какого черта версия пакета не должна этого отражать?
Правильнее вопрос — какого чёрта _именно версия_ должна это отражать, тем более если архитектура поддерживается отдельно?

Здравствуйте, ·, Вы писали:

Надоел спор ради спора. Одни решили 220 вольт, другие 110. Вот и semver — ровно об этом же. В целом — хорошо, на практике не всегда это то, что нужно.

F>> Каким образом тогда 1.0.0+x86 и 1.0.0+x64 будут различимы? Вообще архитектура — это так же часть версии артефакта, однако никакого предшествования тут быть не может, и они естественно должны обрабатываться специальным образом. (Т.е. выбираем правильный пакет, в зависимости от таргета или рантайма).
·>Это часть идентификатора артифакта, но не версии. Идентификатор артифакта — многомерный, не надо пихать всё в одно измерение.
Об этом и речь. Многомерных имен файлов не бывает. Как и имен пакетов. Сегодняшние пакетные менеджеры начали использовать semver, самые модные — не дают дополнительных измерений. Какой тут уж semver. Накой хрен его совать туда где ему совершенно не место или он недостаточен?
У софта бывают и функциональные ограничения. И они важны. Поэтому версия есть версия. Что туда пихать — решает автор.

·>То что им "удобно" (а скорее всего это просто изобретение какого-нибудь идиота-менеджера, которого, надеюсь, уже уволили, но менять это сложно и не хотят тратить на это время-деньги), не означает что использование semver не будет удобнее.
У них ещё параллельная есть версия в скобочках. Инопланетяне.

F>>·>А когда прописываешь зависимости, ты же указываешь mono "4.0.3.20", а не "4.0.3.20+dfsg-1~xamarin2". Правильно понимаю?
F>> В большинстве случаев да. Но ты волен прописать и полную версию.
·>Но это, как мне кажется, не рекомендуется и используется только как workaround.
Если мы хотим получать полную репродукцию — то прийдется указывать столько информации, сколько достаточно для идентификации конкретной версии, конкретного артефакта.
В контроллируемых случаях (как и с debian), и как и то, что пытается сделать semver — как раз дать понимание этих изменений. Вместе с тем, оно ничего не гарантирует.

F>>·>Для маркетинга продуктов хоть "XYZ", но внутри должно быть A.B.C — чтобы сисадмины могли это в своих puppet/chef-скриптах писать и программисты легко интегрироваться.
F>> Ввиду той самой "reproducible build" — софт один хрен должен ссылаться на конкретные версии. А апгрейдить зависимости — по требованию / предлагать.
·>И как предлагать-то? Предлагать апдейт "15.28.24.64.4532" до "15.28.24.86.4532"?
Это забота пакетного менеджера, его возможностей и совместимости. Если такую версию вдруг можно в него засунуть — то вероятно есть и ручки этим управлять. Впрочем 4532 — в данной схеме — номер билда, и без изменения A.B.C скорее всего не публикуется.

F>> А для того, что бы ссылаться на любую версию (представимую ввиде строки) — вообще никакая схема версионирования не нужна. Ссылаться же на часть версии, и выбирать последнюю — это — уже соглашение и ответственность. Последствия и риски должен понимать прежде всего тот, кто ссылается не на конкретную версию, а на её часть.
·>И на совести кто релизит конкретную версию.
На совести того кто релизит — это обеспечивать соглашение. При этом риски того, что всё в конечном продукте развалится, от того что он ссылается на неполные версии — остаются. Новые версии — всегда потенциально несут новые баги.

F>> Что бы что-то рационально решить, сначала нужно иррационально почувствовать, предложить и внедрить. Софтостроение и "инжерная дисциплина" заканчиваются в университетах.
·>Уже прочувстовали и предложили sevmer, осталось внедрять, зачем ходить по тем же граблям?
Потому, что он в таком виде каком он есть (semver) — нахрен не нужен. Это всё тоже самое, что и традиционно используемое, только разбавленное словами из MUST/NOT, и откровенной отсебятиной по поводу пререлиз меток и их форматов.

Здравствуйте, ·, Вы писали:

F>> Так рождаются пакеты somelib-platform-arch которых быть как бы и не должно быть.
·>Почему? Ибо someapp-platform-archX будет зависеть именно от somelib-platform-archX разных версий. Не имеет смысл делать someapp for archX зависимой от somelib-platform-archY.

Потому, что в таком случае необходимо вручную разрешать связи между platform/arch. Если среда выполнения или целевая платформа — windows, x64 — то тебе необходим именно этот пакет. Всё остальное тебя не интересует. Как только ты захочешь билдить под 3 платформы и 2-3 архитектуры — тебе прийдется переписывать зависимости под каждую из них. Универсального способа основанного на конвенциях — тут не будет, т.к. одни банально делают somelib-arch-platform, другие — используют разные имена платформ.
Что бы это разрешить без поддержки опять таки со стороны пакетного менеджера, создают поддержку в пакетном менеджере и используют мета-пакеты, извиняюсь, за тавтологию.
Очевидно, что это не единственное решение.

F>> Даже если конкретный менеджер пакетов или репозиторий имеет встроенную поддержку платформ и архитектур — какого черта версия пакета не должна этого отражать?
·>Правильнее вопрос — какого чёрта _именно версия_ должна это отражать, тем более если архитектура поддерживается отдельно?

Потому, что версией продукта является любая его публикация в любой форме. Выпустил 2 версии x64 и x86 — это два разных цифровых продукта.

Здравствуйте, fddima, Вы писали:

F>>> Так рождаются пакеты somelib-platform-arch которых быть как бы и не должно быть.
F>·>Почему? Ибо someapp-platform-archX будет зависеть именно от somelib-platform-archX разных версий. Не имеет смысл делать someapp for archX зависимой от somelib-platform-archY.

F> Потому, что в таком случае необходимо вручную разрешать связи между platform/arch.
F> Если среда выполнения или целевая платформа — windows, x64 — то тебе необходим именно этот пакет. Всё остальное тебя не интересует. Как только ты захочешь билдить под 3 платформы и 2-3 архитектуры — тебе прийдется переписывать зависимости под каждую из них. Универсального способа основанного на конвенциях — тут не будет, т.к. одни банально делают somelib-arch-platform, другие — используют разные имена платформ.
F> Что бы это разрешить без поддержки опять таки со стороны пакетного менеджера, создают поддержку в пакетном менеджере и используют мета-пакеты, извиняюсь, за тавтологию.
F> Очевидно, что это не единственное решение.
Не понял. А альтернатива-то какая? И так, и так вручную. С т.з. указания платформы — какая разница как прописывать зависимость как "somelib, version=1.2.3-x86" или "somelib-x86, version=1.2.3"?
Зато с точки зрения [полу]автоматического апдейта — второе гораздо юзабельнее.

F> Потому, что версией продукта является любая его публикация в любой форме. Выпустил 2 версии x64 и x86 — это два разных цифровых продукта.
Да почему версией-то?!!! Частью идентификатора конкретного билда — да, но не версией!

Здравствуйте, fddima, Вы писали:

F> Надоел спор ради спора. Одни решили 220 вольт, другие 110. Вот и semver — ровно об этом же. В целом — хорошо, на практике не всегда это то, что нужно.
Заменить всю проводку и оборудование в масштабах страны — одно, а заменить нумерацию версий — друоге. От аршинов таки избавились, надеюсь и от сентиметальных версий постепенно отойдут.

F>·>Это часть идентификатора артифакта, но не версии. Идентификатор артифакта — многомерный, не надо пихать всё в одно измерение.
F> Об этом и речь. Многомерных имен файлов не бывает. Как и имен пакетов. Сегодняшние пакетные менеджеры начали использовать semver, самые модные — не дают дополнительных измерений. Какой тут уж semver. Накой хрен его совать туда где ему совершенно не место или он недостаточен?
F> У софта бывают и функциональные ограничения. И они важны. Поэтому версия есть версия. Что туда пихать — решает автор.
Не понимаю — зачем. В чём необходимость-то поганить именно версию?

F>·>Но это, как мне кажется, не рекомендуется и используется только как workaround.
F> Если мы хотим получать полную репродукцию — то прийдется указывать столько информации, сколько достаточно для идентификации конкретной версии, конкретного артефакта.
F> В контроллируемых случаях (как и с debian), и как и то, что пытается сделать semver — как раз дать понимание этих изменений. Вместе с тем, оно ничего не гарантирует.
Это понятно. Во время сборки используются точные версии. А во время автоматизированного апдейта зависимостей можно использовать semver правила.

F>·>И как предлагать-то? Предлагать апдейт "15.28.24.64.4532" до "15.28.24.86.4532"?
F> Это забота пакетного менеджера, его возможностей и совместимости. Если такую версию вдруг можно в него засунуть — то вероятно есть и ручки этим управлять. Впрочем 4532 — в данной схеме — номер билда, и без изменения A.B.C скорее всего не публикуется.
Т.е. правильный путь это к каждой зависимости писать специальный телепатический плагин, определяющий правила, которые чувствует автор. Так что-ли? Или таки пинать авторов, чтобы они натягивали semver в их уникальное чувствование мира?

F>>> Что бы что-то рационально решить, сначала нужно иррационально почувствовать, предложить и внедрить. Софтостроение и "инжерная дисциплина" заканчиваются в университетах.
F>·>Уже прочувстовали и предложили sevmer, осталось внедрять, зачем ходить по тем же граблям?
F> Потому, что он в таком виде каком он есть (semver) — нахрен не нужен. Это всё тоже самое, что и традиционно используемое, только разбавленное словами из MUST/NOT, и откровенной отсебятиной по поводу пререлиз меток и их форматов.
А что нужно-то? Отрицая — предлагай.