С новой версией изменяю только одну из 3 цифр PropertyGroup/Version. Больше никаких премудростей и больше нигде версия не прописана. И потом билд-скрипт, запускаемый вручную, генерит версию NuGet-пакета.
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
S>С новой версией изменяю только одну из 3 цифр PropertyGroup/Version. Больше никаких премудростей и больше нигде версия не прописана. И потом билд-скрипт, запускаемый вручную, генерит версию NuGet-пакета.
S>Но подумал что это как-то слишком просто.
Здравствуйте, DiPaolo, Вы писали:
DP>Зависит от языка/пакетного менеджера. В основном принято, как я вот выше написал. Но могут быть нюансы в разных языках и их пакетных менеджерах.
См. в каком форуме задан вопрос — всем все понятно.
Re: Версии библиотек и NuGet-пакетов - как сделали вы?
Здравствуйте, 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", т.е. к номеру версии дописывается хэш коммита, ветка, конфигурация сборки, признак наличия незакомиченных изменений в репозитории.
Серёжа Новиков,
программист
Re[2]: Версии библиотек и NuGet-пакетов - как сделали вы?
Здравствуйте, Doom100500, Вы писали D>А борги уже несколько лет от этого отказываются (Chrome, Firefox, GNOME ...)
Ну это зависит от продукта. В их случае это имеет смысл (вы же о версиях 100.x+ и 2022.04), т.к. очень широкий охват аудитории, частые релизы, плюс многие Фреймворк затачиваются на это + маркетинг
Для большинства АПИ, CLI и десктопных утилит с мажорными релизами раз в год/несколько лет и чуть более частыми минорными релизами + багфиксы, и не такой большой базой пользователей имеет смысл семвер.
Патриот здравого смысла
Re[3]: Версии библиотек и NuGet-пакетов - как сделали вы?
Здравствуйте, Ночной Смотрящий, Вы писали:
D>>А борги уже несколько лет от этого отказываются (Chrome, Firefox, GNOME ...) НС>Семвер это не про end user продукты. В первом же абзаце: НС>
НС>MAJOR version when you make incompatible API changes
API бывает только у сервисов, у интерйесов или dll библиотек API не бывает? Это универсальная нумерация, т.к. изменения бывают как
в коробочном, так и в сервисном софте.
Кодом людям нужно помогать!
Re[5]: Версии библиотек и NuGet-пакетов - как сделали вы?
Здравствуйте, Sharov, Вы писали:
S>API бывает только у сервисов, у интерйесов или dll библиотек API не бывает?
Бывает. Но десктопные продукты обычно не делают это API публичным.
S> Это универсальная нумерация, т.к. изменения бывают как S>в коробочном, так и в сервисном софте.
Тем не менее разрабатывалось оно под публичные библиотеки, так что крайне странно кивать на гуевые приложения, да еще с историей гораздо старше самого semver.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[6]: Версии библиотек и NuGet-пакетов - как сделали вы?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>API бывает только у сервисов, у интерйесов или dll библиотек API не бывает? НС>Бывает. Но десктопные продукты обычно не делают это API публичным.
Они не мог использовать библиотеки (утилиты и т.п.), которые исп. публичные API?
S>> Это универсальная нумерация, т.к. изменения бывают как S>>в коробочном, так и в сервисном софте. НС>Тем не менее разрабатывалось оно под публичные библиотеки, так что крайне странно кивать на гуевые приложения, да еще с историей гораздо старше самого semver.
Я не вижу логики, что из того факта, что поминается публичное API и придумано позже, следует, что это не
годится для гуи приложений. Какой-нибудь log4net или подобное не может что-ли жить по semver?
Кодом людям нужно помогать!
Re[7]: Версии библиотек и NuGet-пакетов - как сделали вы?
Здравствуйте, Sharov, Вы писали:
S>>>API бывает только у сервисов, у интерйесов или dll библиотек API не бывает? НС>>Бывает. Но десктопные продукты обычно не делают это API публичным. S>Они не мог использовать библиотеки (утилиты и т.п.), которые исп. публичные API?
Могут. Но в пример были приведены явно версии продуктов, а не версии каких то публичных API.
НС>>Тем не менее разрабатывалось оно под публичные библиотеки, так что крайне странно кивать на гуевые приложения, да еще с историей гораздо старше самого semver. S>Я не вижу логики, что из того факта, что поминается публичное API и придумано позже, следует, что это не S>годится для гуи приложений.
Где я писал что не годится? Был задан вопрос, почему семвер не используется в хроме и фаерфоксе, я ответил. А то что ты там себе придумал дополнительно — я за это не отвечаю.
S>Какой-нибудь log4net или подобное не может что-ли жить по semver?
А он разве не живет (я не в курсе)? Здесь вроде все прилично выглядит.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[8]: Версии библиотек и NuGet-пакетов - как сделали вы?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Sharov, Вы писали:
S>>Они не мог использовать библиотеки (утилиты и т.п.), которые исп. публичные API? НС>Могут. Но в пример были приведены явно версии продуктов, а не версии каких то публичных API.
И что, какая разница?
НС>>>Тем не менее разрабатывалось оно под публичные библиотеки, так что крайне странно кивать на гуевые приложения, да еще с историей гораздо старше самого semver. S>>Я не вижу логики, что из того факта, что поминается публичное API и придумано позже, следует, что это не S>>годится для гуи приложений. НС>Где я писал что не годится? Был задан вопрос, почему семвер не используется в хроме и фаерфоксе, я ответил.
НС>Семвер это не про end user продукты. В первом же абзаце:
Кроме ff и хрома end user продуктов не существует?
S>>Какой-нибудь log4net или подобное не может что-ли жить по semver? НС>А он разве не живет (я не в курсе)? Здесь вроде все прилично выглядит.
Ну да, вполне себе end user продукт, где user == developer.
Кодом людям нужно помогать!
Re[9]: Версии библиотек и NuGet-пакетов - как сделали вы?
Здравствуйте, Sharov, Вы писали:
S>>>Они не мог использовать библиотеки (утилиты и т.п.), которые исп. публичные API? НС>>Могут. Но в пример были приведены явно версии продуктов, а не версии каких то публичных API. S>И что, какая разница?
В предыдущих сообщениях ответ на этот вопрос есть.
S>Кроме ff и хрома end user продуктов не существует?
Я отвечал на конкретное сообщение. Что за дурацкая привычка приписывать мне какие то обобщения?
НС>>А он разве не живет (я не в курсе)? Здесь вроде все прилично выглядит. S>Ну да, вполне себе end user продукт, где user == developer.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[10]: Версии библиотек и NuGet-пакетов - как сделали вы?
Здравствуйте, Ночной Смотрящий, Вы писали:
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".
Дата билда — это вообще что-то эфемерное. Билды в идеале должны быть детерминистичны: из одного состояния исходников получается побайтово один и тот же бинарник — независимо от того, в какую дату ты его собираешь.
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Версии библиотек и NuGet-пакетов - как сделали вы?
XZ>Получается, что двумя первыми цифрами мажор.минор рулит человек (проставляя тэг в репозитории), третья цифра задаёт последовательность — всегда можно понять, кто свежее, а четвёртая разруливает ситуации, если вдруг сборка происходит из двух соседних веток на коммитах с одинаковым порядковым номером.
Здравствуйте, GarryIV, Вы писали:
GIV>Есть же https://semver.org/ зачем велосипед изобретать?
Этот велосипед в специфику моего проекта не заезжает, поэтому приходится изобретать другой.
Хочется автоматической нумерации версий (после вручную проставленных major.minor), автоматической выгрузки на сервер обновлений, автоматического обновления на клиентах, и это всё ещё при автоматических билдах, да в разных ветках (master, beta, feature/####), да ещё с выгрузкой на три среды (dev, beta, prod), где серверы обновлений требуют разных билдов — типа, на dev только Debug, на beta только Release, на prod — только Release, и только из ветки master.
Серёжа Новиков,
программист
Re[4]: Версии библиотек и NuGet-пакетов - как сделали вы?
Здравствуйте, Xander Zerge, Вы писали:
XZ>Хочется автоматической нумерации версий (после вручную проставленных major.minor), автоматической выгрузки на сервер обновлений, автоматического обновления на клиентах, и это всё ещё при автоматических билдах, да в разных ветках (master, beta, feature/####), да ещё с выгрузкой на три среды (dev, beta, prod), где серверы обновлений требуют разных билдов — типа, на dev только Debug, на beta только Release, на prod — только Release, и только из ветки master.
И в чем проблема с semver?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[5]: Версии библиотек и NuGet-пакетов - как сделали вы?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>И в чем проблема с semver?
В необходимости проставлять номер патча руками. Когда двое пилят один модуль каждый в своей ветке, а потом свои правки накатывают на среды сначала dev, потом beta, начинается чехарда.
Вот тут, например, можно наблюдать феерию: https://github.com/ChartIQ/finsemble-seed.git
Куча коммитов, бранчей, тэгов и всё крутится вокруг нумерования, в итоге у них появляются перлы, когда 8.0.0 рождается из 7.0.1, а 7.3.5 из 8.0.1, причём 8.0.1 растёт не из 8.0.0, а из 7.0.1.
Понятно, что люди что-то курят, и по-нормальному это должно выглядеть получше, но вот такой вот пример прямо перед глазами.
Поэтому предпочитаю иметь автоматическую систему нумерования, построенную на простых чётких правилах, притом не зависящую от контента, а только от текущего коммита в репозитории, которую человек не сможет случайно сломать.
Ну а то, что система не следует semver — не беда. Главное, что сервер обновлений её понимает и раздаёт клиентам кому что надо, а на улицу АПИ мы не вывешиваем.
Серёжа Новиков,
программист
Re[6]: Версии библиотек и NuGet-пакетов - как сделали вы?
