Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 71771 invoked from network); 26 Jun 2007 06:52:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Jun 2007 06:52:34 -0000 Received: (qmail 16111 invoked by uid 500); 26 Jun 2007 06:52:37 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 15872 invoked by uid 500); 26 Jun 2007 06:52:36 -0000 Mailing-List: contact axis-cvs-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-cvs@ws.apache.org Received: (qmail 15861 invoked by uid 500); 26 Jun 2007 06:52:36 -0000 Delivered-To: apmail-ws-axis2-cvs@ws.apache.org Received: (qmail 15858 invoked by uid 99); 26 Jun 2007 06:52:36 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Jun 2007 23:52:36 -0700 X-ASF-Spam-Status: No, hits=-99.5 required=10.0 tests=ALL_TRUSTED,NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [140.211.11.3] (HELO eris.apache.org) (140.211.11.3) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Jun 2007 23:52:32 -0700 Received: by eris.apache.org (Postfix, from userid 65534) id C54D01A981A; Mon, 25 Jun 2007 23:52:11 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r550714 - /webservices/axis2/trunk/java/xdocs/release-process.html Date: Tue, 26 Jun 2007 06:52:11 -0000 To: axis2-cvs@ws.apache.org From: chatra@apache.org X-Mailer: svnmailer-1.1.0 Message-Id: <20070626065211.C54D01A981A@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Author: chatra Date: Mon Jun 25 23:52:10 2007 New Revision: 550714 URL: http://svn.apache.org/viewvc?view=rev&rev=550714 Log: minor update Modified: webservices/axis2/trunk/java/xdocs/release-process.html Modified: webservices/axis2/trunk/java/xdocs/release-process.html URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/release-process.html?view=diff&rev=550714&r1=550713&r2=550714 ============================================================================== --- webservices/axis2/trunk/java/xdocs/release-process.html (original) +++ webservices/axis2/trunk/java/xdocs/release-process.html Mon Jun 25 23:52:10 2007 @@ -1,56 +1,57 @@ - - - - Axis2 Release Process - - - - -

Release Process

- -

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

- - - + + + + Axis2 Release Process + + + + + +

Release Process

+ +

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-cvs-unsubscribe@ws.apache.org For additional commands, e-mail: axis-cvs-help@ws.apache.org