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: [EMAIL PROTECTED] "Davanum Srinivas" <[EMAIL PROTECTED]> 04/23/2007 11:44 AM Please respond to [email protected] To [email protected] cc Subject Re: [axis2] Release process +1 from me. thanks, dims On 4/23/07, David Illsley <[EMAIL PROTECTED]> wrote: > Hi Glen, > Comprehensive, sensible, overdue. +1 > David > > On 23/04/07, Glen Daniels <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > David Illsley - IBM Web Services Development > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
