Return-Path: Delivered-To: apmail-db-derby-commits-archive@www.apache.org Received: (qmail 88122 invoked from network); 11 Mar 2008 20:22:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Mar 2008 20:22:15 -0000 Received: (qmail 92923 invoked by uid 500); 11 Mar 2008 20:22:12 -0000 Delivered-To: apmail-db-derby-commits-archive@db.apache.org Received: (qmail 92900 invoked by uid 500); 11 Mar 2008 20:22:12 -0000 Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: "Derby Development" List-Id: Delivered-To: mailing list derby-commits@db.apache.org Received: (qmail 92889 invoked by uid 99); 11 Mar 2008 20:22:12 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Mar 2008 13:22:12 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.130] (HELO eos.apache.org) (140.211.11.130) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Mar 2008 20:21:32 +0000 Received: from eos.apache.org (localhost [127.0.0.1]) by eos.apache.org (Postfix) with ESMTP id 33E0CD2DB for ; Tue, 11 Mar 2008 20:21:52 +0000 (GMT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Apache Wiki To: derby-commits@db.apache.org Date: Tue, 11 Mar 2008 20:21:52 -0000 Message-ID: <20080311202152.4571.73186@eos.apache.org> Subject: [Db-derby Wiki] Update of "DerbySnapshotOrRelease" by DyreTjeldvoll X-Virus-Checked: Checked by ClamAV on apache.org Dear Wiki user, You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification. The following page has been changed by DyreTjeldvoll: http://wiki.apache.org/db-derby/DerbySnapshotOrRelease ------------------------------------------------------------------------------ = Releases = - == high level time line == + == High level time line == - once before release: + Once before release: * volunteer for release manager and announce this * create wiki pages (main, buddytesting, platform testing, app testing) for release * troll for buddies for buddytesting @@ -15, +15 @@ * ensure you have all required tools and files. * ensure your KEYS are in place, and signed. * create packaging.properties based on packaging.tmpl - for each release candidate: + For each release candidate: * drive bug list to zero * add new section to testing wiki pages * arrange for appropriate version numbers in JIRA @@ -34, +34 @@ * bump version * update release wiki page * call for vote - once after candidate passes vote: + Once after candidate passes vote: * tally vote & announce * put files on mirrors * create web page for release * update STATUS file * deploy to maven repository - == release process steps details == + == Release process steps details == === Before a candidate can be generated === @@ -53, +53 @@ 1. Volunteer as release manager (or try to enlist one) - Since only committers have the necessary access to Apache resources to shephard a release to its completion, a committer must volunteer to be the release manager. Usually (hopefully) someone will volunteer if it is clear there is demand for a release. A release manager is under no obligation to finish once they volunteer, and another committer can pick up and complete their work, or even produce a competing release if so desired. + Since only committers have the necessary access to Apache resources to shepherd a release to its completion, a committer must volunteer to be the release manager. Usually (hopefully) someone will volunteer if it is clear there is demand for a release. A release manager is under no obligation to finish once they volunteer, and another committer can pick up and complete their work, or even produce a competing release if so desired. 1. For major releases, create a new branch for the release, in both the code and docs trees. @@ -61, +61 @@ svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/docs/trunk/ https://svn.apache.org/repos/asf/db/derby/docs/branches/{branchname}/ -m "Created the {branchname} doc branch"}}} - 1. After creating the branch, bump the version number on '''trunk'''. There is not currently an ant target for bumping the version number on the trunk so you need to edit `tools/ant/properties/release.properties` on trunk by hand. Bump the major/minor properties as appropriate, zero out the maint property (if it isn't zero already), and ensure the beta flag is set to true (if it isn't already): + 1. After creating the branch, bump the version number on '''trunk'''. There is not currently an ant target for bumping the version number on the trunk so you need to edit `tools/ant/properties/release.properties` on trunk by hand. Bump the major/minor properties as appropriate, zero out the maint property (if it isn't zero already), and ensure the beta flag is set to true (if it isn't already). E.g. after bumping from 10.4 to 10.5 `release.properties` should look similar to: - - {{{vi tools/ant/properties/release.properties - }}} - + {{{#Wed Jul 19 08:21:42 PDT 2006 + drdamaint=0 + maint=0000000 + major=10 + minor=5 + eversion=10.5 + beta=true + copyright.comment=Copyright 1997, 2008 The Apache Software Foundation or its licensors, as applicable. + vendor=The Apache Software Foundation}}} It is probably a good idea to update to the head of trunk, and do a clean build (`ant clobber; ant all`) and run some tests before committing the change. + [[Anchor(BranchVersion)]] - /!\ '''Under construction''' /!\ - 1. On the '''new branch''', edit `tools/ant/properties/release.properties` and update the value of the `maint` property. The exact value of depends on the type of release (feature, update or snapshot). For a new feature release the value will typically be {{{maint=1000000 }}} This will set the version string for the branch to {{{..1.0 (beta) }}} - The relationship between the `maint` property and the version number reported by `sysinfo` is given by the following equation: `maint=100000*3rd+4th`, (or `maint=1000000*fixpack+point` as described in the [http://db.apache.org/derby/papers/versionupgrade.html Derby Versioning Scheme]. Note that a "fixpack" of 0 overrides the `beta` property in `tools/ant/properties/release.properties` and tags the version string with "alpha"). + The relationship between the `maint` property and the version number reported by `sysinfo` is given by the following equation: `maint=100000*3rd+4th`, (or `maint=1000000*fixpack+point` as described in the [http://db.apache.org/derby/papers/versionupgrade.html Derby Versioning Scheme]. Note that a "fixpack" of 0 overrides the `beta` property in `tools/ant/properties/release.properties` and tags the version string with "alpha"). See also the description of how to [#ReleaseCandidate spin a release candidate]. It is probably a good idea do a clean build (`ant clobber; ant all`) and run some or all tests before committing this change to the branch. @@ -154, +158 @@ relnotes.src.reports= #sane=}}} - special consideration for windows users: + Special consideration for windows users: * ant sign, the last step in the ant release process, may not work. try it out before the release time is there; if you cannot do this, you may achieve the same using the following script * similarly, you may use a script to verify the release @@ -214, +218 @@ === For each release candidate === + [[Anchor(ReleaseCandidate)]] ==== Check-ins just before generating release artifacts ==== - 1. Bump the version number, adjust the beta flag and check in the new version. + 1. Set the beta property to false. Bump the point (4th digit) if required, and check in the new version. - The third and fourth parts of the version are combined into a single property, maint, where maint = (third digit * 1000000) + fourth digit. Also, if this is a major/minor (feature) release, you should remove the beta flag at this time. You should update tools/ant/properties/release.properties by hand and then run: + The third and fourth parts of the version are combined into a single property, maint, where maint = (third digit * 1000000) + fourth digit. Also, if this is a major/minor (feature) release, you should remove the beta flag at this time. Note that removing the beta flag will not have an effect unless the 3rd digit (fixpack) is greater than 0, since version numbers with fixpack=0 always are considered alpha. For feature releases fixpack (3rd digit) will normally be set to 1 when the [#BranchCutting branch is cut], but if it isn't, it must be incremented before the release candidate can be created. It will usually ''not'' be necessary to bump point (4th digit) for the ''first'' release candidate, but this step is obviously required for later release candidates. /!\ You should update tools/ant/properties/release.properties by hand and then run: {{{java org.apache.derbyBuild.maintversion2props tools/ant/properties/release.properties tools/release/maintversion.properties}}}