You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Maxim Muzafarov <mm...@apache.org> on 2022/06/08 12:13:02 UTC
.NET Build and Versioning Improvements
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
Re: .NET Build and Versioning Improvements
Posted by Maxim Muzafarov <mm...@apache.org>.
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 <pt...@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 <mm...@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 <mm...@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 <pt...@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 <iv...@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 <iv...@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 <mm...@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
> > > > >
> >
Re: .NET Build and Versioning Improvements
Posted by Pavel Tupitsyn <pt...@apache.org>.
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 <mm...@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 <mm...@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 <pt...@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 <iv...@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 <iv...@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 <mm...@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
> > > >
>
Re: .NET Build and Versioning Improvements
Posted by Maxim Muzafarov <mm...@apache.org>.
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 <mm...@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 <pt...@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 <iv...@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 <iv...@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 <mm...@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
> > >
Re: .NET Build and Versioning Improvements
Posted by Maxim Muzafarov <mm...@apache.org>.
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 <pt...@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 <iv...@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 <iv...@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 <mm...@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
> >
Re: .NET Build and Versioning Improvements
Posted by Pavel Tupitsyn <pt...@apache.org>.
> 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 <iv...@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 <iv...@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 <mm...@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
>
Re: .NET Build and Versioning Improvements
Posted by Ivan Daschinsky <iv...@gmail.com>.
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 <iv...@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 <mm...@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
Re: .NET Build and Versioning Improvements
Posted by Ivan Daschinsky <iv...@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 <mm...@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