Folks, Thans everyone for the review. I've merged the issue.
https://issues.apache.org/jira/browse/IGNITE-17141 On Tue, 14 Jun 2022 at 11:07, Pavel Tupitsyn <ptupit...@apache.org> wrote: > > Maxim, > > Agree with the suffix digit logic change. > Please see my comments on GitHub and in JIRA. > > On Mon, Jun 13, 2022 at 4:16 PM Maxim Muzafarov <mmu...@apache.org> wrote: > > > Pavel, > > > > > > I've found some minor issue with the last digits in thin client > > version - 2.14.0.62943. The last digits is the number of hours passed > > since 01-01-2015 [1]. Due to the last number can't be greater than > > 65534 (UInt16.MaxValue - 1 = 65534) there are only about 100 days left > > to overceed the limit. It seems we need to change it soon. > > > > I've prepared the PR [2] with the following major chagnes: > > - the maven command builds the .NET sources (.NET Core 3.1 and > > Powershell required to be installed); > > - the date format for the 'revision' is - yywwu [3] ('yy' - year, 'ww' > > - week in a year, 'u' - the day number in a week); > > > > From my point of view, the changes [2] looks a bit friendly for the > > version identification and more closely to the maven-style rather than > > having javascript scripts execution. Please, take a look. > > > > > > [1] https://github.com/apache/ignite/blob/master/pom.xml#L568 > > [2] https://github.com/apache/ignite/pull/10087/files > > [3] > > https://github.com/apache/ignite/pull/10087/files#diff-b5a06276719e759fe07dfe6f75d781be5f83d2215179d82bdb195ad035348214R660 > > > > > > > > On Wed, 8 Jun 2022 at 20:06, Maxim Muzafarov <mmu...@apache.org> wrote: > > > > > > Folks, > > > > > > Make sense. > > > Another tricky question is - can we have the following version > > > committed in the source files 2.14.0.0, but when the 'release' profile > > > get activated (or probably the build happened) revision number will > > > changed to 2.14.0.62943? This will be the final release version ready > > > for deploy (with the last digits changed each time build happened). > > > > > > On Wed, 8 Jun 2022 at 16:54, Pavel Tupitsyn <ptupit...@apache.org> > > 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' > > > > > > > > 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 > > > > > > >
