Hi all,

Recent vote of the release didn't go too well because of variying opinions
on where the release candidate artifacts should be provided. With this
discussion I want to get an impression of what people need when they review
a release, and what this means for the requirements and wishes of the
actual release artifact location.

It seems the norm in Apache projects is that artifacts are manually
uploaded by the Release Engineer to somewhere in his personal
people.apache.org web space. So some people prefer this approach. The
upside here is that the release engineer can arrange the location so that
it is as humanly consumable as possible. (Proponents of this approach may
add more upsides that I may not know about.)

However, we're using Maven for the release packaging, signing and
verification, and uploading to a Maven staging repository on
repository.apache.org. This means that we can automize the upload
completely by the existing Maven release process. The location that the
Release Engineer would publish would ultimately be a small Maven
repository. This has the advantage that if you want to review a release
candidate from the perspective of an existing project that is depending on
MetaModel, you could simply consume the repository in your project and
update your dependency version number. That way you could use the release
candidate with very few changes and be able to build, test and run other
projects that depend on it. It also means that the location of the release
candidate artifacts is not on people.apache.org, and that for instance the
source zip file will not be in the root of the upload location, but in:
[root]/org/apache/metamodel/MetaModel/[version]/MetaModel-[version]-source-release.zip.
That location is obviously less easily accessible if you just get the
repository URL.

My opinion:
I like the automatic Maven repository and don't see the point (yet?) in why
it has to be on people.apache.org. That said, I do think the vote email
should contain not just one link to the repository, but also a link
specifically to the source zip. That way the complication of finding the
source zip is overcome for people less accustomed to Maven's repository
layout.

Best regards,
Kasper

Reply via email to