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
> > >
