Здравствуйте, 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, но напрямую я его не редактирую, он генерируется из 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>, а хотелось бы от <Version> (версии пакета).

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

Здравствуйте, 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, но напрямую я его не редактирую, он генерируется из 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> может содержать не только числовые компоненты.