С новой версией изменяю только одну из 3 цифр PropertyGroup/Version. Больше никаких премудростей и больше нигде версия не прописана. И потом билд-скрипт, запускаемый вручную, генерит версию NuGet-пакета.

Но подумал что это как-то слишком просто.

Как делаете вы?

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

S>Как делаете вы?

Определяю такие три версии:

<PropertyGroup>
  <VersionPrefix>0.14.1</VersionPrefix>
  <VersionSuffix>preview</VersionSuffix>
</PropertyGroup>
<PropertyGroup>
  <AssemblyVersion>0.14</AssemblyVersion>
  <FileVersion>$(VersionPrefix)</FileVersion>
</PropertyGroup>

S>С новой версией изменяю только одну из 3 цифр PropertyGroup/Version. Больше никаких премудростей и больше нигде версия не прописана. И потом билд-скрипт, запускаемый вручную, генерит версию NuGet-пакета.

Стандартные <VersionPrefix> и <VersionSuffix>, если заданы, определяют значение MSBuild-свойства <Version>. (Это соответствует версии пакета — тегу <version> в .nuspec, но напрямую я не редактирую .nuspec, он генерируется из MSBuild-свойств.)

<AssemblyVersion> — это уже относится к версии dll'ки. В общем случае она меняется реже, чем версия пакета. Поэтому её значение задаётся явно, а не наследуется от имени пакета — даже если она обычно совпадает с версией пакета. Скажем, в моём примере она будет равна 0.14.0.0 и не будет меняться, если версии сборки бинарно совместимые: 0.14.1, 0.14.2... Если очередной патч пакета 0.14.3 нарушит бинарную совместимость (пусть это и не по SemVer), то версия dll'ки тоже бампнется с 0.14.0.0 до 0.14.3.0. Соответственно, потеряется возможность подменить dll'ку без явной перекомпиляции использующего кода.

<FileVersion> — информационная версия. Её тоже надо указывать, иначе она отнаследует своё значение от <AssemblyVersion>, а хотелось бы от <VersionPrefix> (версии пакета).

Соответственно, в этом примере:
Версия пакета: 0.14.1-preview
Версия dll'ки в пакете: 0.14.0.0
Отображаемая версия в свойствах dll'ки: 0.14.1

Можно при желании добавить

<InformationalVersion>$(Version)</InformationalVersion>

Это «текстовая» версия, отображаемая как «Product version» в Windows. В отличие от <FileVersion> может содержать не только числовые компоненты.

S>С новой версией изменяю только одну из 3 цифр PropertyGroup/Version. Больше никаких премудростей и больше нигде версия не прописана. И потом билд-скрипт, запускаемый вручную, генерит версию NuGet-пакета.

S>Но подумал что это как-то слишком просто.

Все уже давно придумано — https://semver.org

S>Как делаете вы?

Зависит от языка/пакетного менеджера. В основном принято, как я вот выше написал. Но могут быть нюансы в разных языках и их пакетных менеджерах.

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

DP>Зависит от языка/пакетного менеджера. В основном принято, как я вот выше написал. Но могут быть нюансы в разных языках и их пакетных менеджерах.

См. в каком форуме задан вопрос — всем все понятно.

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

S>С новой версией изменяю только одну из 3 цифр PropertyGroup/Version. Больше никаких премудростей и больше нигде версия не прописана. И потом билд-скрипт, запускаемый вручную, генерит версию NuGet-пакета.
S>Как делаете вы?

Заморочился, себе тулзу сделал.
Находит тэг с базой версии по репозиторию, например "1.1", потом считает количество коммитов от тэга до коммита, из которого билдится сборка, это — третья цифра, например "1.1.231", и ещё от того же коммита берётся пара байт его хэша — это четвёртая цифра, и получается "1.1.231.37920".

Получается, что двумя первыми цифрами мажор.минор рулит человек (проставляя тэг в репозитории), третья цифра задаёт последовательность — всегда можно понять, кто свежее, а четвёртая разруливает ситуации, если вдруг сборка происходит из двух соседних веток на коммитах с одинаковым порядковым номером.
Ещё в сборку пишу в текстовое поле ProductVersion что-то типа "1.1.231.37920 a1b2c3d4 master release uncommitted", т.е. к номеру версии дописывается хэш коммита, ветка, конфигурация сборки, признак наличия незакомиченных изменений в репозитории.

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

DP>Все уже давно придумано — https://semver.org

А борги уже несколько лет от этого отказываются (Chrome, Firefox, GNOME ...)

Здравствуйте, Doom100500, Вы писали
D>А борги уже несколько лет от этого отказываются (Chrome, Firefox, GNOME ...)

Ну это зависит от продукта. В их случае это имеет смысл (вы же о версиях 100.x+ и 2022.04), т.к. очень широкий охват аудитории, частые релизы, плюс многие Фреймворк затачиваются на это + маркетинг

Для большинства АПИ, CLI и десктопных утилит с мажорными релизами раз в год/несколько лет и чуть более частыми минорными релизами + багфиксы, и не такой большой базой пользователей имеет смысл семвер.

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

D>А борги уже несколько лет от этого отказываются (Chrome, Firefox, GNOME ...)

Семвер это не про end user продукты. В первом же абзаце:

MAJOR version when you make incompatible API changes

Здравствуйте, Ночной Смотрящий, Вы писали:

D>>А борги уже несколько лет от этого отказываются (Chrome, Firefox, GNOME ...)
НС>Семвер это не про end user продукты. В первом же абзаце:
НС>

НС>MAJOR version when you make incompatible API changes

API бывает только у сервисов, у интерйесов или dll библиотек API не бывает? Это универсальная нумерация, т.к. изменения бывают как
в коробочном, так и в сервисном софте.

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

S>API бывает только у сервисов, у интерйесов или dll библиотек API не бывает?

Бывает. Но десктопные продукты обычно не делают это API публичным.

S> Это универсальная нумерация, т.к. изменения бывают как
S>в коробочном, так и в сервисном софте.

Тем не менее разрабатывалось оно под публичные библиотеки, так что крайне странно кивать на гуевые приложения, да еще с историей гораздо старше самого semver.

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>API бывает только у сервисов, у интерйесов или dll библиотек API не бывает?
НС>Бывает. Но десктопные продукты обычно не делают это API публичным.

Они не мог использовать библиотеки (утилиты и т.п.), которые исп. публичные API?

S>> Это универсальная нумерация, т.к. изменения бывают как
S>>в коробочном, так и в сервисном софте.
НС>Тем не менее разрабатывалось оно под публичные библиотеки, так что крайне странно кивать на гуевые приложения, да еще с историей гораздо старше самого semver.

Я не вижу логики, что из того факта, что поминается публичное API и придумано позже, следует, что это не
годится для гуи приложений. Какой-нибудь log4net или подобное не может что-ли жить по semver?

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

S>>>API бывает только у сервисов, у интерйесов или dll библиотек API не бывает?
НС>>Бывает. Но десктопные продукты обычно не делают это API публичным.
S>Они не мог использовать библиотеки (утилиты и т.п.), которые исп. публичные API?

Могут. Но в пример были приведены явно версии продуктов, а не версии каких то публичных API.

НС>>Тем не менее разрабатывалось оно под публичные библиотеки, так что крайне странно кивать на гуевые приложения, да еще с историей гораздо старше самого semver.
S>Я не вижу логики, что из того факта, что поминается публичное API и придумано позже, следует, что это не
S>годится для гуи приложений.

Где я писал что не годится? Был задан вопрос, почему семвер не используется в хроме и фаерфоксе, я ответил. А то что ты там себе придумал дополнительно — я за это не отвечаю.

S>Какой-нибудь log4net или подобное не может что-ли жить по semver?

А он разве не живет (я не в курсе)? Здесь вроде все прилично выглядит.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Sharov, Вы писали:

S>>Они не мог использовать библиотеки (утилиты и т.п.), которые исп. публичные API?
НС>Могут. Но в пример были приведены явно версии продуктов, а не версии каких то публичных API.

И что, какая разница?

НС>>>Тем не менее разрабатывалось оно под публичные библиотеки, так что крайне странно кивать на гуевые приложения, да еще с историей гораздо старше самого semver.
S>>Я не вижу логики, что из того факта, что поминается публичное API и придумано позже, следует, что это не
S>>годится для гуи приложений.
НС>Где я писал что не годится? Был задан вопрос, почему семвер не используется в хроме и фаерфоксе, я ответил.

НС>Семвер это не про end user продукты. В первом же абзаце:

Кроме ff и хрома end user продуктов не существует?

S>>Какой-нибудь log4net или подобное не может что-ли жить по semver?
НС>А он разве не живет (я не в курсе)? Здесь вроде все прилично выглядит.

Ну да, вполне себе end user продукт, где user == developer.

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

S>>>Они не мог использовать библиотеки (утилиты и т.п.), которые исп. публичные API?
НС>>Могут. Но в пример были приведены явно версии продуктов, а не версии каких то публичных API.
S>И что, какая разница?

В предыдущих сообщениях ответ на этот вопрос есть.

S>Кроме ff и хрома end user продуктов не существует?

Я отвечал на конкретное сообщение. Что за дурацкая привычка приписывать мне какие то обобщения?

НС>>А он разве не живет (я не в курсе)? Здесь вроде все прилично выглядит.
S>Ну да, вполне себе end user продукт, где user == developer.

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>Кроме ff и хрома end user продуктов не существует?
НС>Я отвечал на конкретное сообщение. Что за дурацкая привычка приписывать мне какие то обобщения?

На основе этого ответа было сделано неверное обобщение, а именно:

Семвер это не про end user продукты.

Это увт. неверно.

S>>Ну да, вполне себе end user продукт, где user == developer.
НС>

Ну, началось... Что не так?

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

Q>Соответственно, в этом примере:
Q>Версия пакета: 0.14.1-preview
Q>Версия dll'ки в пакете: 0.14.0.0
Q>Отображаемая версия в свойствах dll'ки: 0.14.1

Вот почему с версионностью творится бардак и непонимание новичками (я тоже ниструя не понимаю в этом месиве) — потому что сама MS налепила какое-то дилетантское г***но и теперь придумывает "обходные врапперы" для решения своих же проблем.
Что мешает иметь ОДНУ версию?? Живут же линуксятники со своим 1.2.3.4 форматом — и ничё, всё работает!
Тут единственный камень преткновения — декларация совместимого диапазона версий. Есть приложение, у него есть libJSON 1.2.3.4; Вместо неё можно подсовывать абсолютно всё, начинающееся с "1.2+" (и загрузчик DLL-ек должен это сам понимать). Версия 1.3.8.1 — подходит. Версия 2.0.1.5 — уже нет. Что тут сложного-то??
И зачем в версии слова "preview" — вообще непонятно... это твои личные проблемы, что ты выпускаешь дикую бетту в паблик. Есть версия, есть правило совместимости. Всё.

Забыл добавить: четвёртая цифра наиболее полезна для кодирования даты билда, что-то вроде "YYMMDD". Не уверен только, что узколобые писаки предусмотрели 32 бита для неё.

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

B>Что мешает иметь ОДНУ версию??

Пакет и dll'ки, входящие в пакет — разные сущности. Почему им обязательно иметь одну версию? Может, часть содержимого пакета не изменилась с прошлого релиза.

B>Живут же линуксятники со своим 1.2.3.4 форматом — и ничё, всё работает!

Ты говоришь о неких линуксятниках, как о какой-то однородной группе.
Нет, они не живут «со своим 1.2.3.4 форматом». Они живут с теми соглашениями, которые в том стеке, который они используют. Для node.js одно, для чего-нибудь ещё — другое. Хотя сейчас почти все сошлись на использовании трёхкомпонентного формата major.minor.patch, независимо от того, реализуют ли SemVer или нет.

B>Тут единственный камень преткновения — декларация совместимого диапазона версий. Есть приложение, у него есть libJSON 1.2.3.4; Вместо неё можно подсовывать абсолютно всё, начинающееся с "1.2+" (и загрузчик DLL-ек должен это сам понимать).

Ну вот в .ΝΕΤ загрузчик на какие-то соглашения не закладывается, и самовольно не интерпретирует.

B>Версия 1.3.8.1 — подходит. Версия 2.0.1.5 — уже нет. Что тут сложного-то??

Тут сложного по крайней мере всё. Хотя бы то, что сохранение совместимости — это скорее исключение, чем правило. Почти любое изменение публичных типов на C# ломает совместимость, на уровне исходников, бинарников или поведения. Т.е. если рассматривать мажорную версию как признак совместимости, то почти каждый релиз должен её увеличивать.

B>И зачем в версии слова "preview" — вообще непонятно... это твои личные проблемы, что ты выпускаешь дикую бетту в паблик.

Это удобно для внутреннего использования. Как только меняется исходный код после релиза, сразу же бампается версия и добавляется суффикс «-preview». Как только версия библиотеки готова к релизу, суффикс убирается. Так удобно отличать опубликованные версии от промежуточных.

B>Забыл добавить: четвёртая цифра наиболее полезна для кодирования даты билда, что-то вроде "YYMMDD".

Дата билда — это вообще что-то эфемерное. Билды в идеале должны быть детерминистичны: из одного состояния исходников получается побайтово один и тот же бинарник — независимо от того, в какую дату ты его собираешь.

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


XZ>Получается, что двумя первыми цифрами мажор.минор рулит человек (проставляя тэг в репозитории), третья цифра задаёт последовательность — всегда можно понять, кто свежее, а четвёртая разруливает ситуации, если вдруг сборка происходит из двух соседних веток на коммитах с одинаковым порядковым номером.

Есть же https://semver.org/ зачем велосипед изобретать?

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

GIV>Есть же https://semver.org/ зачем велосипед изобретать?

Этот велосипед в специфику моего проекта не заезжает, поэтому приходится изобретать другой.
Хочется автоматической нумерации версий (после вручную проставленных major.minor), автоматической выгрузки на сервер обновлений, автоматического обновления на клиентах, и это всё ещё при автоматических билдах, да в разных ветках (master, beta, feature/####), да ещё с выгрузкой на три среды (dev, beta, prod), где серверы обновлений требуют разных билдов — типа, на dev только Debug, на beta только Release, на prod — только Release, и только из ветки master.

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

XZ>Хочется автоматической нумерации версий (после вручную проставленных major.minor), автоматической выгрузки на сервер обновлений, автоматического обновления на клиентах, и это всё ещё при автоматических билдах, да в разных ветках (master, beta, feature/####), да ещё с выгрузкой на три среды (dev, beta, prod), где серверы обновлений требуют разных билдов — типа, на dev только Debug, на beta только Release, на prod — только Release, и только из ветки master.

И в чем проблема с semver?