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