L>Ну как сказать для себя, я программист на предприятии, просто раньше я за номер версии использовал номер ревизии из svn а тут появилось свободное время и решил может есть какие-то стандарты на этот счет чтобы не придумывать велосипед решил поискать, поспрашивать.
Если номер версии не торчит в названии продукта на продажу сторонним покупателям и у вас нет дикомфорта в использовании номера ревизии из svn в качестве номера версии, то и менять ничего не надо (ну только если делать уж совсем нечего).
L>Вы имеете ввиду что если продукт с версией 5.0 перестали покупать то просто меняем версию на 6.0 без изменений в коде и ждем пополнения средств?
Не это. В ПО постоянно вносятся исправления, какие-то фичи добавляются, пока продажи идут хорошо, то выпускаются версии 5.1, 5.2 и т.д. Можно рассылать бесплатные апдейты. Когда продажи проседают, в какой-то момент объявляете не 5.3, а 6.0 с предложением обновить лицензию платно. Ну и в новой версии, конечно, надо иконки перерисовать .
Здравствуйте, Dym On, Вы писали:
L>>Вы имеете ввиду что если продукт с версией 5.0 перестали покупать то просто меняем версию на 6.0 без изменений в коде и ждем пополнения средств? DO>Не это. В ПО постоянно вносятся исправления, какие-то фичи добавляются, пока продажи идут хорошо, то выпускаются версии 5.1, 5.2 и т.д. Можно рассылать бесплатные апдейты. Когда продажи проседают, в какой-то момент объявляете не 5.3, а 6.0 с предложением обновить лицензию платно. Ну и в новой версии, конечно, надо иконки перерисовать .
Помоему вы более просто перефразировали про 5.3 и 6.0 и иконки т.е мы имеем ввиду одно и то же.
Здравствуйте, Dym On, Вы писали:
L>>Ну как сказать для себя, я программист на предприятии, просто раньше я за номер версии использовал номер ревизии из svn а тут появилось свободное время и решил может есть какие-то стандарты на этот счет чтобы не придумывать велосипед решил поискать, поспрашивать. DO>Если номер версии не торчит в названии продукта на продажу сторонним покупателям и у вас нет дикомфорта в использовании номера ревизии из svn в качестве номера версии, то и менять ничего не надо (ну только если делать уж совсем нечего).
Ну как сказать дискомфорт просто захотелось провентилировать этот вопрос возможно как-то причесать, ведь номер ревизии из свн имеет некоторые недостатки возможны скачки версий из-за лишних коммитов, я просто привык в конце дня делать коммит на всякий случай а на следующий день могу сделать ревер мердж и новый коммит в результате получается пропасть между версиями хотя был исправлен всего лишь один баг. Пользователям это вроде не мешает, самому неприятно.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, lvlsynaps, Вы писали:
L>>Вообще эта спецификация не дает определения что такое публичное API, скажем если одна программа занимается только тем что что стягивает данные из сервера с БД и рисует их на экране у нее есть публичное API?
S>Вообще-то даёт, сразу после объяснения, зачем оно вообще нужно: S>
S>В системе с множественными зависимостями выпуск новой версии может быстро превратиться в кошмар. Если спецификации зависимости слишком жесткие, вы находитесь в опасности блокирования выпуска новой версии (невозможность обновить пакет без необходимости выпуска новой версии каждой зависимой библиотеки). Если спецификация зависимостей слишком свободна, вас неизбежно настигнет версионное несоответствие (необоснованное предположение совместимости с будущими версиями).
S>В качестве решения данной проблемы я предлагаю простой набор правил и требований, которые определяют, как назначаются и увеличиваются номера версий. Для того чтобы эта система работала, вам необходимо определить публичный API. Он может быть описан в документации или определяться самим кодом. Главное, чтобы этот API был ясным и точным. Однажды определив публичный API, вы сообщаете об изменениях в нём особым увеличением номера версий.
S>Кэп намекает, что в случае, когда с софтом работает напрямую пользователь, в качестве API выступает UI. В смысле, не кнопочки и не пиксели, речь про набор возможностей и поведение программы.
зачем тогда использовать для этого аббревиатуру API у которой уже есть четкое определение, если эта спецификация дает для нее такие плавающие рамки, и каждый сам решать что такое API может действительно эта система больше для библиотек подходит?
S>Посмотрите на это дело с точки зрения it-директора. Нужно скажем, установить софт для n+1-го пользователя, вышла новая версия 1.2.4. Имеет ли смысл её ставить, если у остальных пользователей стоит 1.1.0 и обучение проводилось именно на этой версии?
S>В случае, если версии соответствуют semver ответ очевиден. Если нет — нет.
Здравствуйте, lvlsynaps, Вы писали:
L>зачем тогда использовать для этого аббревиатуру API у которой уже есть четкое определение, если эта спецификация дает для нее такие плавающие рамки, и каждый сам решать что такое API может действительно эта система больше для библиотек подходит?
Ну так способ нумерации в semver заточен в первую очередь на разруливание зависимостей библиотек/пакетов.
Для других задач его никто не запрещает использовать, провести аналогию API <-> UI как бы несложно
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, lvlsynaps, Вы писали:
L>>зачем тогда использовать для этого аббревиатуру API у которой уже есть четкое определение, если эта спецификация дает для нее такие плавающие рамки, и каждый сам решать что такое API может действительно эта система больше для библиотек подходит?
S>Ну так способ нумерации в semver заточен в первую очередь на разруливание зависимостей библиотек/пакетов. S>Для других задач его никто не запрещает использовать, провести аналогию API <-> UI как бы несложно
Слушай, можешь привести простой пример работы данной системы как он изначально задуман для каких нибудь выдуманных программ?
Здравствуйте, lvlsynaps, Вы писали:
L>Вообще эта спецификация не дает определения что такое публичное API, скажем если одна программа занимается только тем что что стягивает данные из сервера с БД и рисует их на экране у нее есть публичное API?
Если посмотреть на ситуацию под другим углом, то можно считать, что это не программа стягивает, а в программу засовывают. И тогда изменение формата засовываемых в нее данных будет фактическим изменением публичного API.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, lvlsynaps, Вы писали:
L>Слушай, можешь привести простой пример работы данной системы как он изначально задуман для каких нибудь выдуманных программ?
Не вопрос На примере той же студии:
VS 2015 - 14.0.0
VS 2015 + хотфикс - 14.0.123
VS 2015 update 1 - 14.1.0
VS 2017 - 15.0.0
решение, что относить к релизу, что к хотфиксу, что к обновлению — за разработчиками. Общий подход — см рекомендации на semver.org.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, lvlsynaps, Вы писали:
L>>Слушай, можешь привести простой пример работы данной системы как он изначально задуман для каких нибудь выдуманных программ?
S>Не вопрос На примере той же студии: S>
S>решение, что относить к релизу, что к хотфиксу, что к обновлению — за разработчиками. Общий подход — см рекомендации на semver.org.
Ну подожди я просил как изначально задуман семвер , ведь VS это не библиотека а IDE самостоятельная программа какой публичный API она объявляет?
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, lvlsynaps, Вы писали:
L>>Вообще эта спецификация не дает определения что такое публичное API, скажем если одна программа занимается только тем что что стягивает данные из сервера с БД и рисует их на экране у нее есть публичное API?
Н>Если посмотреть на ситуацию под другим углом, то можно считать, что это не программа стягивает, а в программу засовывают. И тогда изменение формата засовываемых в нее данных будет фактическим изменением публичного API.
Да можно и так посмотреть, а вот другой случай конкретно мой: программа затягивает данные из одной системы генерирует другие на основе их и передает в другую систему. Но при этом это не библиотека а самостоятельный проект, который использует библиотеки но самое важное что проект с другими системами не может быть использован т.к их нет и не планируется.
Здравствуйте, lvlsynaps, Вы писали:
S>>решение, что относить к релизу, что к хотфиксу, что к обновлению — за разработчиками. Общий подход — см рекомендации на semver.org. L>Ну подожди я просил как изначально задуман семвер , ведь VS это не библиотека а IDE самостоятельная программа какой публичный API она объявляет?
Давай так: определись сам, какой ответ ты хочешь услышать, сравни с текстом на semver.org и определись, подходит оно тебе или нет.
Копировать цитаты и объяснять смысл фразы "использовать с умом" как-то надоело
Ладно один-два раза. Но обсждение на две страницы из-за того, что лень прочитать спецификацию | поискать "semver desktop versioning" — это перебор
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, lvlsynaps, Вы писали:
S>>>решение, что относить к релизу, что к хотфиксу, что к обновлению — за разработчиками. Общий подход — см рекомендации на semver.org. L>>Ну подожди я просил как изначально задуман семвер , ведь VS это не библиотека а IDE самостоятельная программа какой публичный API она объявляет?
S>Давай так: определись сам, какой ответ ты хочешь услышать, сравни с текстом на semver.org и определись, подходит оно тебе или нет. S>Копировать цитаты и объяснять смысл фразы "использовать с умом" как-то надоело
S>Ладно один-два раза. Но обсждение на две страницы из-за того, что лень прочитать спецификацию | поискать "semver desktop versioning" — это перебор
S>Тем более что вопрос обсуждался неоднократно и ответы везде совпадают: S>http://programmers.stackexchange.com/questions/255190/how-does-semantic-versioning-apply-to-programs-without-api S>http://programmers.stackexchange.com/questions/200002/semantic-versioning-for-desktop-applications
Я хочу понять на примере для чего создан семвер и в чем его сильные стороны, потому что для десктопных приложений это натягивание.
Здравствуйте, lvlsynaps, Вы писали:
L>Я хочу понять на примере для чего создан семвер и в чем его сильные стороны, потому что для десктопных приложений это натягивание.
В топике на это отвечали по меньшей мере трижды. И на самом сайте на нескольких языках — тоже.
Здравствуйте, lvlsynaps, Вы писали: L>Да можно и так посмотреть, а вот другой случай конкретно мой: программа затягивает данные из одной системы генерирует другие на основе их и передает в другую систему.
Что будет, когда формат данных в одной из систем поменяется?
Например, если вы тянете данные напрямую из СУБД, и поменялась структура таблиц.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinix, Вы писали:
S>Заслуга semver в том, что весь этот зоопарк был утрамбован в простой и однозначный стандарт с рекомендациями, FAQ и поддержкой почти всех частных случаев вплоть до текстовых меток. Ну и ещё в том, что он поспел как раз к волне хайпа на git и к отмиранию понятия "номер ревизии".
Заслуга semver теперь в том, что на него пытаются натянуть всё подряд, на той самой волне хайпа. В том числе и нюгет ушел в несознанку.
SemVer, просто подходит его автору и его видению мира, а в нормальном понимании версий — это ерунда, потому, что разный софт традиционно версионируится по разному. OpenSSL к примеру 1.0.2d. Во-вторых, эта вся семантика-романтика — не учитывает природу и натуру софта и/или целевого использования. Скажем, если мы говорим о семантике и совместимости API на уровне исходных кодов или бинарных сборок? Потому, что, изменившиеся зависимости — должны пораждать новые версии продуктов, вне зависимости от того меняют они API или нет. При чём, иногда изменение некоторых зависимостей — должны порождать новые мажорные версии, при этом надо ещё как-то конечным пользователям донести и свой версию своего контракта (API). Есть и случаи, когда софт собирается под кастомера, и тут скорее всего хоть и будет базовая A.B.C — но остальная номенклатура будет зависить от внутреннего процесса (рассматривать это как отдельный продукт, или как суб-продукт). В общем, есть тысяча точек вращения, и semver не подходит для всего, хотя в него вписывается и многое.
А вот ещё примеры из реальной жизни:
1. У Intel встречаются версии 15.28.24.64.4229 и 15.28.24.4229. 64 — это x64. Тем не менее они используют именно такую нумерацию.
2. OpenSSL и другие, — схема X.Y.Zp — где p — hotfix/patch после X.Y.Z.
3. Debian-like: (на примере mono) 3.2.8+dfsg-4ubuntu1.1 и 4.0.3.20-0xamarin1. Хотя бывают и более замысловатые: 2.6.3+dfsg-1~xamarin2. При этом там используется почти обычный alphanumeric формат, и исходную версию продукта никто не меняет (и большинство из них нормально влазят).
4. Ну и наконец, версия Windows не ограничивается A.B.C.D. А номер билда выглядит приблизительно так: 10525.0.amd64fre.th2_release.150812-1658.
А так да — всё просто и однозначно. Особенно если перестать использовать дурацкие псеводстандарты, которым вдобавок никто не следует.
Здравствуйте, fddima, Вы писали:
f> SemVer, просто подходит его автору и его видению мира, а в нормальном понимании версий — это ерунда, потому, что разный софт традиционно версионируится по разному.
Ключевое слово тут "традиционно". Нет никакой рациональной необходимости в этом зоопарке. Поэтому и предлагается стандарт.
f> OpenSSL к примеру 1.0.2d. Во-вторых, эта вся семантика-романтика — не учитывает природу и натуру софта и/или целевого использования. Скажем, если мы говорим о семантике и совместимости API на уровне исходных кодов или бинарных сборок?
Исходный код обязан каждый раз порождать идентичную бинарную сборку. Поэтому — какая разница? Если не так — значит в процессе разработки бардак и нет такого понятия как reproducible build.
f> Потому, что, изменившиеся зависимости — должны пораждать новые версии продуктов, вне зависимости от того меняют они API или нет. При чём, иногда изменение некоторых зависимостей — должны порождать новые мажорные версии, при этом надо ещё как-то конечным пользователям донести и свой версию своего контракта (API).
А какая разница конечному пользователю почему изменилось поведение — из-за изменения самого кода или какой-то зависимости? И да, делаем мажорную версию, если надо.
f> Есть и случаи, когда софт собирается под кастомера, и тут скорее всего хоть и будет базовая A.B.C — но остальная номенклатура будет зависить от внутреннего процесса (рассматривать это как отдельный продукт, или как суб-продукт). В общем, есть тысяча точек вращения, и semver не подходит для всего, хотя в него вписывается и многое.
По-моему стандарт достаточно универсален, поэтому можно вписать всё.
f> А вот ещё примеры из реальной жизни: f> 1. У Intel встречаются версии 15.28.24.64.4229 и 15.28.24.4229. 64 — это x64. Тем не менее они используют именно такую нумерацию.
И что? Традиция. платформу можно положить в build metadata или в имя продукта. Ведь очевидно, что ...64... и ...86... это, очевидно, не увеличение версии.
f> 2... f> 3... f> 4...
ubuntu и windows можно объяснить тем, что это не совсем версии продукта, а идентификаторы сборок: оригинальный номер продукта (mono 4.0.3.20) + номер и обёртки чтобы это положить в dep-package list.
f> А так да — всё просто и однозначно. Особенно если перестать использовать дурацкие псеводстандарты, которым вдобавок никто не следует.
А что использовать-то? Каждый должен сочинять то на что горазд?
Заслуга semver теперь в том, что на него пытаются натянуть всё подряд, на той самой волне хайпа. В том числе и нюгет ушел в несознанку.
Повсеместное форсирование semver — не учитывает главного, — а именно, потребностей разработчика, и сложности (или простоты) софта. Или вообще назначения.
>Ключевое слово тут "традиционно". Нет никакой рациональной необходимости в этом зоопарке. Поэтому и предлагается стандарт.
Это не стандарт, и даже не рекомендация. В мире пишут люди с лева направо и справа налево, почему бы не писать всем справа на лево? Ну что бы по стандарту? Нет никакой реальной необходимости как либо ограничивать разработчиков в выборе схемы версионирования, тем более что в основном все популярные схемы — основаны на последовательности идентификаторов, с индикацией важности изменения определяемой позицией каждого идентификатора. 1.0.2d — точно такая же версия.
f>> OpenSSL к примеру 1.0.2d. Во-вторых, эта вся семантика-романтика — не учитывает природу и натуру софта и/или целевого использования. Скажем, если мы говорим о семантике и совместимости API на уровне исходных кодов или бинарных сборок? ·>Исходный код обязан каждый раз порождать идентичную бинарную сборку. Поэтому — какая разница? Если не так — значит в процессе разработки бардак и нет такого понятия как reproducible build.
Исходный код никому ничего не обязан, и идентичные бинарники не генерируются при тех же равных и так. Кроме того артефакты могут зависеть от установленного софта и его обновлений. Поэтому "reproducible build" гарантировать всё равно никто не сможет, особенно с течением времени. Легче все артефакты хранить, в том числе и с .pdb.
Кроме того библиотека версии A.B.C может поставляться в 3-х упаковках: с UTF8 строками, с UTF16 строками и UTF32. Как автору библиотеки — тебе может быть фиолетово, для тебя — это всё есть A.B.C. Для потребителей артефактов — это 3 разных версии, с несовместимым ABI.
f>> Потому, что, изменившиеся зависимости — должны пораждать новые версии продуктов, вне зависимости от того меняют они API или нет. При чём, иногда изменение некоторых зависимостей — должны порождать новые мажорные версии, при этом надо ещё как-то конечным пользователям донести и свой версию своего контракта (API). ·>А какая разница конечному пользователю почему изменилось поведение — из-за изменения самого кода или какой-то зависимости? И да, делаем мажорную версию, если надо.
Тут обратная ситуация. Нам как потребителям-девелоперам всё ещё интересная версия, которая бы не была рандомным числом.
·>По-моему стандарт достаточно универсален, поэтому можно вписать всё.
За рамками A (A.B.C) — ничего универсального нет. Любой постфикс делает версию 'prerelease'. Префиксы вдобавок ограничены странными правилами. Невозможно указать postrelease. Вообще в интернете если поискать есть полно критики semver.
f>> 1. У Intel встречаются версии 15.28.24.64.4229 и 15.28.24.4229. 64 — это x64. Тем не менее они используют именно такую нумерацию. ·>И что? Традиция. платформу можно положить в build metadata или в имя продукта. Ведь очевидно, что ...64... и ...86... это, очевидно, не увеличение версии.
Build metadata не являются частью версии в semver2 и из сравнения исключаются. При этом очевидно что 64 и 86 — есть весьма разные билды, которые живут параллельно -> следовательно платформу невозможно положить в build metadata. Что касатеся очевидности, то предшествование версий обеспечивается принятой схемой версионирования, и некоторые из них — очевидны. Другие нет. При этом семантика схемы — обеспечивается автором. На ручнике или с помощью тулзов. Поэтому кроме как говорить о возможной рекомендации — не приходится.
·>ubuntu и windows можно объяснить тем, что это не совсем версии продукта, а идентификаторы сборок: оригинальный номер продукта (mono 4.0.3.20) + номер и обёртки чтобы это положить в dep-package list.
В случае с debian — это именно версия пакета. Т.к. этот пакет собирается особым образом, наносятя патчи, конфигурируются и прочие вещи. Это позволяет пушить изменения (исправления), в том числе и секьюрити фиксы, для библиотек, базовая версия которых к тому моменту — не изменилась. Вместе с тем, это не параллельное версионирование. Это больше похоже на бранч.
f>> А так да — всё просто и однозначно. Особенно если перестать использовать дурацкие псеводстандарты, которым вдобавок никто не следует. ·>А что использовать-то? Каждый должен сочинять то на что горазд?
Ещё раз — semver пихать куда не попадя — не нужно.
Для продуктов может быть достаточно A.B. Для библиотек A.B.C, мы всё равно все к этом привыкли. Для иных случаев — ровно то, что решит автор, если он чувствует в этом необходимость.
Короче говоря — как только будете заниматься маппингом технологических версий на внешние, только лишь для того, что бы угодить тулзам, которые с другими схемами версий не работают — тогда станет всё понятно.
Здравствуйте, ·, Вы писали:
·> ubuntu и windows можно объяснить тем, что это не совсем версии продукта, а идентификаторы сборок: оригинальный номер продукта (mono 4.0.3.20) + номер и обёртки чтобы это положить в dep-package list.
Это отличается потому, что ты, собирая свой продукт, будешь добавлять зависимость mono версии "4.0.3.20", а не "4.0.3.20+dfsg-1~xamarin2", а дальше package manager сам разберётся что делать с этими +-~.
Заслуга semver теперь в том, что на него пытаются натянуть всё подряд, на той самой волне хайпа. В том числе и нюгет ушел в несознанку.
Так натягивается же.
f> Повсеместное форсирование semver — не учитывает главного, — а именно, потребностей разработчика, и сложности (или простоты) софта. Или вообще назначения.
Учитывает достаточно чтобы покрыть и сложный (не путаем с переусложнённым), и простой софт.
f> >Ключевое слово тут "традиционно". Нет никакой рациональной необходимости в этом зоопарке. Поэтому и предлагается стандарт.
f> Это не стандарт, и даже не рекомендация.
Спецификация, набор правил, соглашение. Какая разница?
f> В мире пишут люди с лева направо и справа налево, почему бы не писать всем справа на лево? Ну что бы по стандарту?
Плохая аналогия. Не надо путать культурные ценности и инженерную дисциплину.
f> Нет никакой реальной необходимости как либо ограничивать разработчиков в выборе схемы версионирования, тем более что в основном все популярные схемы — основаны на последовательности идентификаторов, с индикацией важности изменения определяемой позицией каждого идентификатора. 1.0.2d — точно такая же версия.
Зачем у тебя в розетке 220 вольт? Ведь нет никакой необходимости, и 22, и 2200 — точно такие же вольты.
f> ·>Исходный код обязан каждый раз порождать идентичную бинарную сборку. Поэтому — какая разница? Если не так — значит в процессе разработки бардак и нет такого понятия как reproducible build.
f> Исходный код никому ничего не обязан, и идентичные бинарники не генерируются при тех же равных и так. Кроме того артефакты могут зависеть от установленного софта и его обновлений. Поэтому "reproducible build" гарантировать всё равно никто не сможет, особенно с течением времени. Легче все артефакты хранить, в том числе и с .pdb.
Бардак, что ещё сказать... У нас нет "установленного софта". Точная версия jdk, python, и прочего явно указана в исходном коде.
f> Кроме того библиотека версии A.B.C может поставляться в 3-х упаковках: с UTF8 строками, с UTF16 строками и UTF32. Как автору библиотеки — тебе может быть фиолетово, для тебя — это всё есть A.B.C. Для потребителей артефактов — это 3 разных версии, с несовместимым ABI.
Для потребителей это три разных библиотеки. Потребитель скорее всего будет использовать одну из них (или так же делать три упаковки) и отслеживать изменения именно "A.B.C".
f> ·>А какая разница конечному пользователю почему изменилось поведение — из-за изменения самого кода или какой-то зависимости? И да, делаем мажорную версию, если надо. f> Тут обратная ситуация. Нам как потребителям-девелоперам всё ещё интересная версия, которая бы не была рандомным числом.
Не понял мысль. Что-то у тебя падежов не склоняется.
f> ·>По-моему стандарт достаточно универсален, поэтому можно вписать всё.
f> За рамками A (A.B.C) — ничего универсального нет. Любой постфикс делает версию 'prerelease'. Префиксы вдобавок ограничены странными правилами. Невозможно указать postrelease.
А какой смысл вложен в этот postrelease? Почему нельзя сделать 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.
Хех...
f> Build metadata не являются частью версии в semver2 и из сравнения исключаются.
И правильно что исключаются. Сравнение нужно для чего? Для того, чтобы принять решение — нужно ли обновление версии или нет и оценить сложность. Я вот помню уже попадал на такую граблю, когда выбирал последний релиз смотря на строки типа "15.28.24.64.4229", "15.28.24.64.4532", "15.28.24.86.4532" .
f> При этом очевидно что 64 и 86 — есть весьма разные билды, которые живут параллельно -> следовательно платформу невозможно положить в build metadata. Что касатеся очевидности, то предшествование версий обеспечивается принятой схемой версионирования, и некоторые из них — очевидны. Другие нет. При этом семантика схемы — обеспечивается автором. На ручнике или с помощью тулзов. Поэтому кроме как говорить о возможной рекомендации — не приходится.
Но уж точно платформу нельзя класть в значимый номер версии.
Понятно, конечно, что можно делать. Но это вовсе не значит, что так нужно делать.
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-скриптах писать и программисты легко интегрироваться.
f> Для иных случаев — ровно то, что решит автор, если он чувствует в этом необходимость.
Извини, но софтостроение — инженерная дисциплина. Там не чувствовать надо, а рационально решать.
f> Короче говоря — как только будете заниматься маппингом технологических версий на внешние, только лишь для того, что бы угодить тулзам, которые с другими схемами версий не работают — тогда станет всё понятно.
semver ничего о внешних (маркетинговых) версиях не говорит, хоть Lollipop, хоть Vista.
.
В мире пишут люди с лева направо и справа налево, почему бы не писать всем справа на лево? Ну что бы по стандарту? Нет никакой реальной необходимости как либо ограничивать разработчиков в выборе схемы версионирования, тем более что в основном все популярные схемы — основаны на последовательности идентификаторов, с индикацией важности изменения определяемой позицией каждого идентификатора. 1.0.2d — точно такая же версия.