Thanks guys, I guess we could continue with release VOTE using the staging repo.
I have set the svn pub sub for MetaModel to push our release artifacts later to the dist location. Ankit, as the RE for this release, can resend the [VOTE] thread with RC files in the staging area. - Henry On Sat, Dec 7, 2013 at 4:18 AM, Matt Franklin <[email protected]> wrote: > 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 >>
