lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: JIRA Issue Tracker - Needs Updates
Date Tue, 25 Apr 2017 04:24:27 GMT
On 2017-04-24, Shad Storhaug wrote:

>> There are just a few rules that we need to adhere to, and all it is going to cost
us is a formal vote that will run for about three days.

> No problem. So, yes it would appear we need a release vote.

> I take it I need to supply the binaries (NuGet packages) and Itamar
> will prepare them before the vote? If so, another question...

Actually, for the ASF vote the source packages are way more important
than the binaries. The later are just a convenience. This is true even
though all of our users are going to consume the binaries. But the
release is the source tarball/zip.

Yes. Somebody needs to create the release artifacts including the nuget
packages, PGP sign them, publish them to and call
for a vote.

> We have one package that depends on icu-dotnet, which still has no
> official support for .NET Core. Connie has recently made a PR to
> resolve that, which is currently being worked on. Basically, the
> dependency for Lucene.Net.Icu is missing on NuGet - the reason why the
> project compiles is because there is a temporary package on
> MyGet. Being that this package is not likely to be used by many
> people, it seems silly to hold up the release for this issue. We can
> just provide release notes with instructions on how to get the
> dependency from MyGet (or alternatively don't upload it to MyGet until
> the issue is resolved). But what happens if icu-dotnet for .NET Core
> is released after the packages are created and before they are
> approved?

Is this a likely scenario? The vote should be finished within 72 hours
or so. Worst case we could cancel the vote, adapt the code, build new
artifacts and run a new vote.

> FYI - I have setup the build process to append the short Git commit
> hash to the AssemblyInformationalVersion. While I did that mainly to
> correlate the CI builds to a commit without tagging every build, it
> seems it would also come in handy if there is a delay between when the
> binary is generated and when the tag is applied to the repository.

Sounds good.


View raw message