Hola, What you're proposing is a good process. See comments inline with the way we usually do it at the ASF, at least in the projects I've worked on. Feel free to incorporate or disregard these practices.
On 9/2/06, David E Jones <[EMAIL PROTECTED]> wrote: <snip />
When we do a final release we'll want to do a branch, but I'm not sure if we want to do that for release candidates at this point (unless there is something being developed we want to keep out of the release... ?).
You typically tag (not branch) for non-final releases: RCs, alphas, betas, etc. For a final release, you tag at a minimum, and you branch if the dev team expects significant code evolution, backwards-incompatible changes in the next release, or other major stuff. Remember that you can always branch off a tag at any point in time, there's no rush to do so at the time of release.
1. svn export (either trunk for early RC, or the release branch for a release or later or more isolated RC)
Always always cut the release from its SVN tag. This is essential to reproducing the same build in the future after changes have occurred in the trunk and/or branch. Whether you want to do an svn export or normal checkout is up to you, though usually normal checkout is just fine.
2. for a framework only build: remove the applications directory 3. ant run-install
OK, but it would be worth having two separate distro-creatign targets, one full and one that just ignores the applications directory. That way users can just run ant to create the distro without needing to manually modify the directory tree.
4. zip/tgz and PGP sign
Also remember to generate and MD5 or SHA-1 checksum of each distro.
5. post somewhere for download - perhaps on the wiki until it's official or something?
Before they're official, you have a choice of places. The wiki, the release manager's public_html, a dev.apache.org tree I think.
6. send request for review to Incubator PMC
Vote among the OFBiz people first, then ask the Incubator PMC for a review and include the OFBiz vote results.
7. add links to it on the Apache OFBiz (should we start using AOFBiz?) web site and incubation status page On #5: for the incubator I guess this is different from the main ASF download mirrors and would just go on the web site server or something? If it goes on the web site I guess we should add it to the site directory in SVN, perhaps in a releases sub-directory or something, and then just update on the people.apache.org server and off it goes...
For unofficial releases (i.e. ones not vetted by the OFBiz and Incubator PMCs), see above. You can stick it in SVN if you'd like, but that's not required as it should be trivial to rebuild any release from its SVN tag. For official releases, after the proper voting you put the release files (including PGP and checksums of course) in /www/www.apache.org/dist/[project name]/[version], which gets mirrored worldwide automatically.
Looking at these the next step is to figure out what we need to do for PGP signing. If I understand it right one of the individuals on the PMC would just use their personal key to sign the release. Is that correct?
It's possible. It's also possible for the release manager to generate a special key just for signing ASF releases. Whatever key is used, it should be uploaded to public keyservers like pgp.mit.edu, and should be present in the KEYS file in the root SVN directory for OFBiz, as well as included in the release distributions. It's important for everyone, but especially the release manager, to read http://wiki.apache.org/incubator/SigningReleases.
If this person needs to be in the web of trust and that needs to be done face to face with an ASF member that is already in, then perhaps Jacopo would be the best candidate for this as he can somewhat easily meet with David Welton. Does that sound reasonable? Then Jacopo could just sign this first release.
That's fine and reasonable.
There are some other things we should probably do, like release notes and testing and such. We used to spend quite a bit of time doing those early on which is one reason we stopped doing releases so much: it got to the point where it took a few days to a couple of man-weeks just to go through and prepare everything. There has been quite a lot of testing and fixing going on recently, and we can refer to Si's blog and the Jira tracker in a fairly short and simple release note.
In the long-term, I would hope we can automate much of the testing via JUnit or whatever tool we want. Then the ant dist target would run those tests, and the distros would not be created until all the tests pass.
Does this sound reasonable?
Yup, +1, let's do it. Yoav
