...
Releases heretofore have been done on Windows (both US locale and Japan locale), and thus we feel that the release process is fairly robust for that platform. Batch scripts have been created that ease the process mightily. On Linux there are also scripts which have been used for one release.
Branches and tags
For any release, there should be a release branch. In the past, this branch has been created by the appropriate "svn copy" command from trunk. For example:
svn copy https://svn.apache.org/repos/asf/manifoldcf/trunk https://svn.apache.org/repos/asf/manifoldcf/branches/release-0.6-branch
See below for a description of some automated scripts that do this job now.
A major release will have its own release branch labeled with the release number (e.g. "release-0.6-branch"). A minor release will continue in the appropriate major release branch, and have the required changes pulled up from trunk one at a time. Thus 0.6.1 would be released from "release-0.6-branch" also.
When the time comes to build a release candidate, the release engineer should make an appropriately-labeled copy of the release branch in the "tags" area. For instance:
svn copy https://svn.apache.org/repos/asf/manifoldcf/branches/release-0.6-branch https://svn.apache.org/repos/asf/manifoldcf/tags/release-0.6-RC0
When the release is finally completed, the appropriate tag is then renamed to be the release name, e.g.:
svn move https://svn.apache.org/repos/asf/manifoldcf/tags/release-0.6-RC0 https://svn.apache.org/repos/asf/manifoldcf/tags/release-0.6
Preparing release branch
After you create the release branch, you need to set its version and update CHANGES.txt to be consistent with it being a release version. Here is the basic checklist.
...
release branch
Since this process has been error-prone and is no longer even remotely automatic (due to the unreliability of mvn versions:set), I've written scripts that do the work. Specifically:
...
NOTE: In order to proceed, you MUST have svn 1.7 or higher installed! The ant build scripts require this in order to be able to apply patches on Windows platforms. You will also need GnuPG installed (from http://www.gnupg.org/download/), and have your signing key created and installed (read this: http://www.apache.org/dev/release-signing). Also needed is the utility "pscp.exe", and a properly configured public/private key signon to people.apache.org (which is required to upload artifacts; read here how to set that up: https://www.debian-administration.org/article/530/SSH_with_authentication_key_instead_of_password).
The first step of the build process is to create a release tag for the release candidate:
svn -m "Create RC0 tag for MCF 2.0" copy https://svn.apache.org/repos/asf/manifoldcf/branches/release-2.0-branch https://svn.apache.org/repos/asf/manifoldcf/tags/release-2.0-RC0
The next The first step of the build process is to check out the release branch tagged RC into a work area. Technically it is more correct to check out the tag, but in practice that's not necessary because only the release engineer should be working on the release branch. All other development should be taking place in trunk.:
svn co https://svn.apache.org/repos/asf/manifoldcf/tags/release-2.0.6-branchRC0 myworkarea
Then, check out the release scripts:
...
The release scripts perform all the required fetching of dependencies automatically, through ant. But they do not know how to deal with proxies, so if you have a proxy you will need to figure out how to deal with that.
Next, you will need to create a place to put the release in your people.apache.org public_html area. This directory should be named "apache-manifoldcf-<release_name>". The release candidate will be copied there.check out the ManifoldCF dist/dev svn directory:
svn co https://dist.apache.org/repos/dist/dev/manifoldcf devareaThe final The next step is to fire off the release script itself. You will need to supply your people.apache.org username also, as well as your SSH private key:
cd myworkarea
../release-scripts/release.bat 2.0 .6 kwright c:\passwd\kwright-people.apache.org.ppk
./devarea
Your After being prompted a few times for your key file password, and for your people.apache.org password, your release candidate should be created, copied, and copied committed to an appropriate subdirectory in your user area on people.apache.org, e.g. http://people.apache.org/~kwright/apache-manifoldcf-0.6.Finally, create a tag corresponding to the release candidate, as previously described. Obviously release candidates should start at RC0 and count up sequentiallyof the dist/dev/manifoldcf area.
Calling the vote
Once the artifact has been uploaded to people.apache.org, you should call a vote to release the artifact. This involves sending an email to dev@manifoldcf.apache.org, with the title "[VOTE] Release Apache ManifoldCF xxxx RCnnn". In the vote email, mention where the artifacts can be downloaded from (httphttps://peopledist.apache.org/~<username>repos/dist/dev/manifoldcf/apache-manifoldcf-xxxx), as well as the full svn URL of the tag you created (https://svn.apache.org/repos/asf/manifoldcf/tags/release-xxxx-RCnnnn). The vote must have three +1's from committers, and must be open at least 72 hours.
...
If the vote does not pass, this usually implies that fixes will be made and a new RC created. Fixes usually are committed to trunk first and then pulled up into the release branch using the "svn merge" command, e.g. "svn merge -c ZZZZ https://svn.apache.org/repos/asf/manifoldcf/trunk". Before the creating of the next RC, you should also log into people.apache.org again, and svn move the old artifacts from the public-html/ apache-manifoldcf-XXX directory to public-html/ apache-manifoldcf-XXX/-RCnnnn. Then, upload the new RC as before.
...
When the vote passes, you should check "svn move" the artifacts from your public-html the dist/dev area directly into the svnpubsub svndist/release area. DO NOT REGENERATE THE ARTIFACTS - the community has voted on them and they are the only legal copies you should distribute. Once that is done, you should also use "svn move" to rename the artifact RC tag you created to remove the -RCnnnn suffix from it.
You will also need to commit the artifact to the distribution svn, and update the ManifoldCF website to reflect the new release. The process for doing that involves several steps. The first step is to set up the release for distribution:
...
:
svn -m "Release MCF 2.0" move https://dist.apache.org/repos/dist/dev/manifoldcf/apache-manifoldcf-2.0 https://dist.apache.org/repos/dist/
...
release/manifoldcf
...
/Once that is done, you should also use "svn move" to rename the artifact RC tag you created to remove the -RCnnnn suffix from it.
svn -m "Release RC0" move https://svn
...
...
...
manifoldcf/tags/release-2.0-RC0https://
...
...
...
The second step is to modify the MCF site to reflect the new release. To do this, you must do the following:
...
Publishing the site is covered elsewhere. When that has been completed, you need to remove the old release from the dist area:
- On people.apache.org, check Check out the ManifoldCF dist release area: "svn co https://dist.apache.org/reps/dist/release/manifoldcf"
- svn remove the old release: "svn remove apache-manifoldcf-XXX*"
- Commit the removal
Updating trunk post-release
...