Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (herse.apache.org: domain of barrettj@us.ibm.com designates
 32.97.110.153 as permitted sender)
In-Reply-To: <19e0530f0704230944w7d0370a3ta20496c273943f69@mail.gmail.com>
To: axis-dev@ws.apache.org
MIME-Version: 1.0
Subject: Re: [axis2] Release process
From: Jeff Barrett <barrettj@us.ibm.com>
Message-ID: 
 <OF5D9A6AEC.1532F376-ON862572C6.005C940B-862572C6.005D093F@us.ibm.com>
Date: Mon, 23 Apr 2007 11:55:50 -0500
Content-Type: text/plain; charset="US-ASCII"

Nice!  +1 with one possible caveat....

At one time on the list there was a discussion of doing a "code reformat" 
prior to each release.  I know that's not in the list below, and that's a 
Very Good Thing.  I don't think we should do a code format prior to a 
release (or indeed, ever again); we should be keeping the format correct 
as we commit changes.

Thanks,
Jeff

IBM Software Group - WebSphere Web Services Development
Phone: 512-838-4587 or Tie Line 678-4587
Internet e-mail and Sametime ID: barrettj@us.ibm.com


"Davanum Srinivas" <davanum@gmail.com> 
04/23/2007 11:44 AM
Please respond to
axis-dev@ws.apache.org


To
axis-dev@ws.apache.org
cc

Subject
Re: [axis2] Release process


+1 from me.

thanks,
dims

On 4/23/07, David Illsley <davidillsley@gmail.com> wrote:
> Hi Glen,
> Comprehensive, sensible, overdue. +1
> David
>
> 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
>
>


-- 
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers

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


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