Versions Compared

Key

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

...

dkulp: I'm adding this section to document what worked for ME when maintaining the 2.07.x-fixes branch for the 2.07.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 trunkmaster. Thus, the main job of the fixes branch maintainer is to triage the commits on trunk master and merge pure fixes to the fixes branchbranches, 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:

  1. use svn cp git branch to make a branch. Use URLs for the pathnames or it will take forever.
  2. use bin/pom-version.pl to change the version in the branch
  3. 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.

...

  1. .
  2. On the branch, create a .gitmergeinfo file with a single line of "origin/master" to say the branch will be merging from there.

In trunk/bin, there is a DoMerges.java program that wraps svnmerge.py to assist assists in the merging. If the branch is setup with snvmerge .pygitmergeinfo, if you run it from you the root directory of the checkout directory, it will prompt for every commit on trunk master 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).

Note

Don't manually update the POM versions from X.Y.Z-SNAPSHOT to X.Y.Z, the Maven Release Plugin commands below will automatically take care of that. Also, prior to performing the release you'll need to have your Apache LDAP information configured in your Maven settings.xml file:

Code Block

...
<server>                                                                
   <id>apache.releases.https</id>
   <username>apacheID</username>
   <password>yourLDAPPassword</password>
</server>
...

Then, to actually perform the release, run the below commands.

Note

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. It's recommended you build the release with the lowest JDK version supported by that particular branch (JDK 6 with CXF 2.7.x, JDK 5 for older releases).

No Format

mvn release:prepare -Peverything,jaxws22
mvn release:perform -Peverything,jaxws22

The above commands tag the release, update the poms versions, etc., then build it (off the tag), gpg sign and deploy everything (including source jars and javadoc jars) to the Nexus repository location. When the build is done staging, you next need to login to the Nexus repository and "close" the staging area (click on Staging Repositories in the left-side menu, select the repo you just uploaded and then select the close button.) Closing is very important. After the staging area is closed, note the URL for the staging area as you will need that for the vote.

...

.

...

...

At this point, everything "pre-vote" is done. Call the vote.

...

  • Maven artifacts - After the vote passes, you'll need to promote that staging repository to the main location. Login to Nexus repository location to do that as well, find the staging repository and click the Release button.
  • Distributions - You will need to commit the distributions into the special svn distribution area: https://dist.apache.org/repos/dist/release/cxf
    after you commit 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.

    Code Block
    
    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
    

...