axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Illsley" <>
Subject Re: [axis2] Release process
Date Mon, 23 Apr 2007 16:01:32 GMT
Hi Glen,
Comprehensive, sensible, overdue. +1

On 23/04/07, Glen Daniels <> wrote:
> 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.
> Thanks,
> --Glen
> ===========================================================
> --- 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
> branch.
> * 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:

David Illsley - IBM Web Services Development

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

View raw message