axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ajith Ranabahu" <ajith.ranab...@gmail.com>
Subject Re: [axis2] Release process
Date Mon, 23 Apr 2007 17:03:53 GMT
Hi Glen,
This is great  and definitely +1

Here is something that we need to talk about concretely.

When fixing the bugs for the release how would the commits happen ? I
mean do we do the changes to both the branch and the trunk at the same
time or is it the release manager who has to do the merging ?

>
> On 23/04/07, Glen Daniels <glen@thoughtcraft.com> 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: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> David Illsley - IBM Web Services Development
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>


-- 
Ajith Ranabahu

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message