Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Run with extra flags to skip the code checks and running of the tests
    Code Block
    mvn -Pdeploy,nochecks deploy -Dmaven.test.skip.exec=true
    
  2. HIGHLY RECCOMMENDED: use a "Master Mode" ssh connection to people.apache.org for the scp commands to use. This requires a fairly recent version of ssh. Basically, in your /etc/ssh/ssh_config, make sure you have "ControlPath /tmp/%h-%p-%r" set. Then, in one window, run "ssh -Mv people.apache.org". Then run the deploy in another. The -v on the ssh connection will print things for each connection so you'll know it working. This is MUCH faster as SCP doesn't need to negotiate encryption stuff for every single file, doesn't need to open up lots of connections, etc....

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.3 release. Each Release Manager may have their own style or tools or whatever. This is not a "set in stone" type thing.

Basically, almost all developement 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.

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

For the most part, we now follow the same instructions that the maven team uses.
http://maven.apache.org/developers/release/releasing.html

...