db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "DerbySnapshotOrRelease" by DyreTjeldvoll
Date Tue, 11 Mar 2008 20:21:52 GMT
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 
    {{{<major>.<minor>.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=<location where you want to save/access the xml scripts for generating
release notes>
  #sane=<sane should *not* be set>}}}
  
- 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}}}
  

Mime
View raw message