Сообщение Re: Версии библиотек и NuGet-пакетов от 06.09.2022 10:41
Изменено 06.09.2022 11:21 Qbit86
Re: Версии библиотек и NuGet-пакетов
Здравствуйте, Shmj, Вы писали:
S>Как делаете вы?
Определяю такие три версии:
S>С новой версией изменяю только одну из 3 цифр PropertyGroup/Version. Больше никаких премудростей и больше нигде версия не прописана. И потом билд-скрипт, запускаемый вручную, генерит версию NuGet-пакета.
Стандартные <VersionPrefix> и <VersionSuffix>, если заданы, определяют значение MSBuild-свойства <Version>. (Это соответствует тегу <version> в 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>Как делаете вы?
Определяю такие три версии:
<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, но напрямую я его не редактирую, он генерируется из 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> может содержать не только числовые компоненты.
Re: Версии библиотек и NuGet-пакетов
Здравствуйте, Shmj, Вы писали:
S>Как делаете вы?
Определяю такие три версии:
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
Можно при желании добавить
Это «текстовая» версия, отображаемая как «Product version» в Windows. В отличие от <FileVersion> может содержать не только числовые компоненты.
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> может содержать не только числовые компоненты.