Keep in mind the first Apache release is the hardest. It gets a lot easier from here.
On Tue, Dec 10, 2013 at 8:03 PM, Henry Saputra <[email protected]>wrote: > 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 > >> >
