axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject [axis2] Release process
Date Mon, 23 Apr 2007 15:50:58 GMT
Hi Axis2 developers:

In an effort to coalesce some recent discussion into a policy, here is a 
proposal for how we should manage releases and dealing with SVN.  If we 
can agree on this, I'll check in an HTML version, and we can start 
following these guidelines for our next release.

This is important stuff, please take a moment to read it over and see if 
you agree with the principles.  The goals are 1) minimize "speed bumps" 
to active development, 2) make it easy to manage releases both as 
they're going out and for future bug fixes, 3) make sure we don't lose 
anything and also avoid giant merges.

Please chime in with +1/-1 and/or comments.



--- Cutting a branch

* When a release is ready to go, release manager (RM) puts forward a 
release plan as per standard Apache process, including dates.  This gets 
VOTEd on by the committers.  During this period the trunk is still the 
only relevant source base.

* As soon as a release is approved (or even before), RM should add the 
new version into JIRA as a target.

* At the point where we would normally do the "code freeze" for a 
release, the RM cuts a branch named for the release.  This branch is 
where the release candidates and releases will happen.

* Ideally a release branch is only around for a week or maybe two before 
the release happens.

* The only things that should EVER get checked into the release branch 
are - 1) bug fixes targeted at the release, 2) release-specific updates 
(documentation, SNAPSHOT removal, etc).  In particular new functionality 
does not go here unless it is a solution to a JIRA report targeted at 
the release.

* Normal development continues on the trunk.

--- Dependencies and branches

* The trunk should always be "cutting edge" and as such should usually 
be pointing at SNAPSHOT versions of all dependencies.  This allows for 
continuous integration with our partner projects.

* Soon after a release branch is cut, the RM is responsible for removing 
ALL dependencies on SNAPSHOT versions and replacing them with officially 
released versions.  This change happens only on the release branch.

--- Managing change and issue resolution with a release branch

* The RM goes through JIRA issues and sets "fix for" to point to both 
"NIGHTLY" and the new branched release number for the fixes that are 
targeted for the release after the branch is cut.

* In general, the assignee/coder fixes JIRA issues or makes other 
changes *on the trunk*.  If the JIRA issue is targeted at the release, 
or upon coder's discretion, they then merge the fix over to the release 

* This way the trunk is ALWAYS up-to-date, and we don't have to worry 
about losing fixes that have only been made on the release branch.

* When the assignee resolves an issue, they confirm it's been fixed in 
both branches, if appropriate.

--- Checking changes into the branch

* If bug fixes are needed later for a release which has long since 
happened (to fix user issues, etc), those fixes generally should also 
happen on the trunk first assuming the problem still exists on the trunk.

* There are only two cases where we would ever check anything into the 
branch without first checking it into the trunk.  1) Release specific 
items (release number references, release notes, removal of SNAPSHOTs), 
and 2) if the trunk has moved on in some incompatible way.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message