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
