> As for the last number in .NET version, AFAIK it is used as the unique > build id and is required for nightly builds as nuget doesn't have > functionality a-la maven's 'snapshots'
NuGet supports string suffixes like 2.15.0-nightly1. However, AssemblyVersionAttribute does not. In some cases it is important to avoid having different NuGet packages with assemblies that have the AssemblyVersion inside (dll hell type problems, especially with peer assembly loading). So I suggest keeping the last number for AssemblyVersion and AssemblyFileVersion in SharedAssemblyInfo. This does not affect the NuGet package version. Otherwise, I don't have any objections to adding a new Maven step that builds dotnet, as long as we keep using build.ps1 script. Thanks, Pavel On Wed, Jun 8, 2022 at 4:31 PM Ivan Daschinsky <ivanda...@gmail.com> wrote: > As for the last number in .NET version, AFAIK it is used as the unique > build id and is required for nightly builds as nuget doesn't have > functionality a-la maven's 'snapshots' > > ср, 8 июн. 2022 г. в 16:07, Ivan Daschinsky <ivanda...@gmail.com>: > > > Since nuget packages have been built on the same linux agent as the main > > release, it sounds logical to me that this step can be done within the > > maven lifecycle. > > I am for it, +1 > > > > ср, 8 июн. 2022 г. в 15:13, Maxim Muzafarov <mmu...@apache.org>: > > > >> Hello Igniters, > >> > >> > >> I'd like to simplify the release build for the Apache Ignite. > >> > >> My suggestion here are: > >> 1. Mavenize the building procedure of the 'platform/donet' thin client > >> (use maven with Ant task) > >> 2. Change it's versions to fit the Ignite style. > >> > >> > >> = 1. Build = > >> > >> Add a pom.xml sub-project with a corresponding maven-ant-plugin with a > >> Ant task to build the .NET project when the Apache Ignite project > >> build. We can use here a profile like the numa-allocator does if > >> building the .NET is note required. > >> > >> Such a technique will also allow a variables substitution like the > >> maven-resource-plugin works (e.g. version substitution). > >> > >> Here is an example of how it can be achieved: > >> > >> > https://github.com/apache/ignite/pull/9497/files#diff-77baf2378aa83911a8c3091814db3ff60b7bf328c4ab4850f707717ed96f3d92R107 > >> > >> > >> = 2. Versioning = > >> > >> Currently, the version of .NET thin client (SharedAssemblyInfo.cs [1]) > >> have the following format: > >> 2.14.0.62943 . The format of .NET versions Major.Minor.Patch.Revision > >> (described here [2]). > >> > >> Since the Apache Ignite doesn't have a dedicated releases for the .NET > >> thin client I think the last 'Revision' digits can be always set to > >> zero. So the result version can be: > >> 2.14.0.0 > >> > >> This will allow having the variable substitution also for the version > >> number and omitt the update-version profile usage for the .NET client. > >> > >> > >> = Advantages = > >> > >> - Reduce the code complexity for changing a project version (we don't > >> need the update-versions maven profile); > >> - Build the whole project on the local environment and prepare nuget > >> for the release with a single command; > >> > >> > >> [1] > >> > https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/SharedAssemblyInfo.cs > >> [2] > >> > https://docs.microsoft.com/en-us/nuget/concepts/package-versioning#where-nugetversion-diverges-from-semantic-versioning > >> > > > > > > -- > > Sincerely yours, Ivan Daschinskiy > > > > > -- > Sincerely yours, Ivan Daschinskiy >
