lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shad Storhaug <s...@shadstorhaug.com>
Subject Release
Date Tue, 25 Apr 2017 21:33:03 GMT
Stefan,

I have gone through the procedure and created and signed the release artifacts. The only issue
seems to be that only PMC members are allowed to put the release artifacts into the release
directory.

So, the files can be obtained at http://www.shadstorhaug.com/lucenenet.zip. Please download,
unzip, and upload the contents to the https://dist.apache.org/repos/dist/release/lucenenet/
directory.

Let me know if there is anything out of place, as this is the first time I have tried this.

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

Not sure. On one hand, the original request for adding .NET Core support was nearly a year
ago (https://github.com/sillsdev/icu-dotnet/issues/8). On the other, along with 2 beta releases
already this month, there has been a flurry of activity around Connie's recent pull request
(https://github.com/sillsdev/icu-dotnet/pull/37).

But since beta means a small subset of our users, and International means a small subset of
those users, it isn't likely there will be many complaints.


Thanks,
Shad Storhaug (NightOwl888)


-----Original Message-----
From: Stefan Bodewig [mailto:bodewig@apache.org] 
Sent: Tuesday, April 25, 2017 11:24 AM
To: dev@lucenenet.apache.org
Subject: Re: JIRA Issue Tracker - Needs Updates

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 dist.apache.org/dev 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.

Stefan

Mime
View raw message