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