On Fri, Dec 6, 2013 at 3:18 PM, Kasper Sørensen < [email protected]> wrote:
> 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.) > Uploading to people.apache.org is actually an older practice that has been deprecated. There is now a SVN Pub/Sub system with a staging and dist section that we can ask INFRA to configure for us. > > 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. > We should deploy to repository.apache.org. It ensures are artifacts are synced to Maven central. > > 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. > Bottom line is that it doesn't really matter where the release artifacts are staged; but, the release process MUST comply with the following: 1) Produce a binary-free source package that is the "release" that is voted on 2) Comply with all LICENSE & NOTICE constraints (including ensuring compatible licensing on source inclusions) 3) Reside on dist.apache.org. By policy, a release must be accessible through https://dist.apache.org/repos/dist/release/incubator/metamodel/ A release MAY: 1) Deploy to maven central via repository.apache.org 2) Build "convenience" binaries that include 3rd party dependencies and host these in dist Hope this clears things up. > > Best regards, > Kasper >
