Since we have a new PMC member, Chris, I thought I'd put down more
detail than usual about releases.
There are some changes coming through about discouraging MD5.
There are some simplifications we can do about NOTICE and LICENSE files.
== The "Release"
The "release" is the source-release.zip file that will end up in
/dist/jena/source/.
The files going into /binaries/ and the files going to maven central,
including the copy of "source-release", are "convenience binaries".
Our process is documented at:
https://cwiki.apache.org/confluence/display/JENA/Release+Process
== Update to Apache release policy:
MD5 checksums are being discouraged for the source-release, the file
that goes in https://www.apache.org/dist/jena/source/.
Files uploaded to maven central are not affected - they remain as
md1/sha1/asc - and I think MD5/SHA1 is effectively baked into maven.
The Apache parent POM, does not seem to seem to deal with this so I'm
proposing we add a manual step at about step 10 to calculate sha512
checksums and delete the MD5 checksums
https://cwiki.apache.org/confluence/display/JENA/Release+Process#ReleaseProcess-Step10-UploadtheReleaseCandidate
(and change the download.html page).
== Possible future changes.
Now we are committed to a single release cycle for all modules, there is
no need to have NOTICE and LICENSE files at the top of every module. We
can just have the ones in the top directory which should already be correct.
We do need separate N&L files to go into binaries like the Fuseki sever
jar. These are in "dist/" subdirectories in the codebase.
The W3C test suites need there own files.
== The Process
There are two parts - the basic of an Apache process (conducted
properly, legal clean, signed) and what we as a community decide on top
of that.
Strictly, a vote is at least 3 +1 and a simple majority (you can't veto
a release, that should have happened when the code went into the codebase).
As a community, we haven't pushed through a release on that minimal
basis before. We try to sort things out and do a new release candidate.
Doing a 2nd, 3rd, ... release candidate isn't too bad although not zero
cost. The most bumpy things have been instabilities in the test suite -
unintended order dependencies and with random things on different
hardware. Deciding on a case-by-case basis rather than a set of rules
for all eventualities seems fine to me.
It does not have to be perfect. My view is that the question is "is it
better?" We are shipping fixes and improvement.
We tend to classify modules into two groups: the principle modules which
are a blocker on getting a release out, and rhe rest including legacy
ones (e.g. Fuseki1, SDB). At the moment, jena-maven-tools does not pass
its test suite and is not in the build.
Ultimately, it's the Release Manager decision.
== Voting
The VOTE email will have various links and details in it:
All links are https and to Apache servers.
--------
Proposed dist/ area:
-- URL to the files to go in https://www.apache.org/dist/jena/
-- You must download the "source/" area.
https://dist.apache.org/repos/dist/dev/jena/
Keys:
-- Keys to import to verify the .asc on source-release.zip.-----
https://svn.apache.org/repos/asf/jena/dist/KEYS
Staging repository:
-- URL to the files to go to maven central --
https://repository.apache.org/content/repositories/orgapachejena-?????
Git commit (browser URL):
-- URL to the commit on Apache hardware, not Github.
http://git-wip-us.apache.org/repos/asf/jena/commit/??????
Git Commit Hash:
-- full SHA1 hash of the commit.
-- "[maven-release-plugin] prepare release ..."
Git Commit Tag:
-- The tag. Note that tags in git can be moved later.
-- It is the commit SHA1 that matters.
--------
When voting on a release candidate the following points need to be checked:
+ is there a source archive?
+ is the GPG signatures correct?
+ are the checksums correct?
+ does everything work?
+ can the source archive really be built?
(NB This requires a "mvn install" first time)
+ is there a correct LICENSE and NOTICE file in each artifact
(both source and binary artifacts)?
+ does the NOTICE file contain all necessary attributions?
+ have any licenses of dependencies changed due to upgrades?
if so have LICENSE and NOTICE been upgraded appropriately?
+ does the tag/commit in the SCM contain reproducible sources?
--------
