Deploying snapshots
Snapshots are automatically deployed every night to the Nexus snapshot repository at https://repository.apache.org/content/groups/snapshots-group/ . There is no need to manually deploy snapshots anymore.
Maintaining a fixes branch
dkulp: I'm adding this section to document what worked for ME when maintaining the 2.0.x-fixes branch for the 2.0.x releases. Each Release Manager may have their own style or tools or whatever. This is not a "set in stone" type thing.
Basically, almost all development and fixes and such are usually done by the various developers right on trunk. Thus, the main job of the fixes branch maintainer is to triage the commits on trunk and merge pure fixes to the fixes branch, resolve conflicts, run the tests, and periodically deploy snapshots. For the most part, when things go well, it doesn't take too much time or effort. An hour or two every couple days is about it.
To set up, you'll want to:
- use svn cp to make a branch. Use URLs for the pathnames or it will take forever.
- use bin/pom-version.pl to change the version in the branch
- use svnmerge.py init to set up svnmerge. You may want to run this in both the trunk and the new branch in case you are contemplating bidirectional merges.
These steps work for individual developers who want to go off into a branch in the sandbox to work through something complex.
In trunk/bin, there is a DoMerges.java program that wraps svnmerge.py to assist in the merging. If the branch is setup with snvmerge.py, if you run it from you checkout directory, it will prompt for every commit on trunk to see if you want to "Merge" it, "Block" it, or "Ignore" it. It displays the commit log first so you can see what was involved. You can also check the cxf-commits archive to see the full details of the commit to help decide what action to take. If you select "Merge", it will merge the change and then prompt before committing. That will allow you to look at the merge and resolve any conflicts. (or even revert it if you didn't mean to hit Merge)
Performing a release
The first step is to update the release_notes.txt in the distribution/src/main/release. This file's JIRA list of solved Bugs, Improvements, etc. can be obtained from the "Road Map" JIRA tab, selecting the desired version's Release Notes, and then the Configure Release Notes button (choose Text output).
Then, to actually perform the relesae, run the below commands.
It is suggested to use Maven 2.2.1 for CXF versions <=2.5.x as that has been better tested. For >=2.6.0, Maven 3 is required. Also, since CXF supports Java5, it is recommended that the release be done with a Java5 JDK.
mvn release:prepare -Peverything,jaxws22 mvn release:perform
That will tag the release, update the poms, etc... Then build it (off the tag) and deploy everything (including source jars and javadoc jars) to the Nexus repository location and gpg signs everything. When the build is done staging, you need to login to the Nexus repository and "close" the staging are. That is very important. After the staging are is closed, note the URL for the staging area as you will need that for the vote.
You may encounter error like
INFO Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: PROPFIND request failed on '/repos/asf/!svn/vcc/default'
svn: No such revision 1197023
when run "mvn release:prepare -Peverything,jaxws22" to create tag if you're not in U.S.
This is caused by that the svn server in Europe need some time to sync up to the central server in U.S.
If you encounter it, just wait a minute, and do "mvn release:prepare -Dresume=true -Peverything,jaxws22" which
will pick up the left task from last run.
At this point, everything "pre-vote" is done. Call the vote.
Releasing the artifacts
- Maven artifacts - After the vote passes, you'll need to promote that staging repository to the main location. Login to Nexus to do that as well. See above Maven team release page.
- Distributions - You will need to commit the distributions into the special svn distribution area:
https://dist.apache.org/repos/dist/release/cxf
when the commit done there, they will be live on dist.apache.org fairly quickly, but it will still take time for the mirrors to get copies. It's likely easier to make the directory via an svn command, check out just that directory, and then add the files. The dist area is rather large (400MB or so) so checking out the entire thing may be slow.svn mkdir https://dist.apache.org/repos/dist/release/cxf/2.6.3 svn checkout https://dist.apache.org/repos/dist/release/cxf/2.6.3 .... add files to 2.6.3 ..... svn commit
- Update the download page - around 24 hours after committing the distributions, update the download page, release notes, etc... to point at the new versions.
- Unpack the javadocs from the appropriate cxf-bundle-VERSION-javadocs.jar into the appropriate directory in an svn checkout of https://svn-master.apache.org/repos/infra/websites/production/cxf/content/javadoc
and commit the new version. Make sure any new files are added.
- Unpack the schemas directory from the appropriate cxf-bundle-VERSION.jar and check if any of the schemas in https://svn-master.apache.org/repos/infra/websites/production/cxf/content/schemas
need updating.