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.149 as permitted sender)
In-Reply-To: <462CF6E2.9060808@thoughtcraft.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: 
 <OFA4E50DED.7B965FCD-ON862572C6.0064E96A-862572C6.0065827B@us.ibm.com>
Date: Mon, 23 Apr 2007 13:28:23 -0500
Content-Type: text/plain; charset="US-ASCII"

Hi Glen,

Thanks for the reply.  Sure, we can discuss this again when we're ready to 
cut 1.3. 

The problem we have is that we don't all run IDEA, so we can't mimic the 
changes that would be applied across the entire tree.  If we think the 
reformatting is necessary, one option might be to use Eclipse (or some 
other open source tool) to do the reformats so we all have access to the 
tool.

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


Glen Daniels <glen@thoughtcraft.com> 
04/23/2007 01:11 PM
Please respond to
axis-dev@ws.apache.org


To
axis-dev@ws.apache.org
cc

Subject
Re: [axis2] Release process


Hi Jeff:

+1 to keeping the code formatting all the time, but theoretically that 
means that any changes a project-wide "format code" operation would 
generate should be very minor, just correcting mistakes.  As such I 
still think we should be trying out a format-sweep using the checked-in 
IDEA settings before each release.

How about we bring this up again when we're ready to cut 1.3 and I can 
post a diff of what the formatting run would do to the tree before 
committing?

Thanks,
--Glen

Jeff Barrett wrote:
> 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
>>
>>
> 
> 

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