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 Wed, 30 Apr 2008 08:57:14 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

------------------------------------------------------------------------------
    * update `releaseSummary.xml`, create release notes & changes files
    * clean doc & source trees, then build release artifacts
    * (optional:) build eclipse plugin or get a volunteer to do it for you
-   * sign and place on `people.apache.org` web site (in your public_html directory)
+   * sign and place on `people.apache.org` web site (in your `public_html directory`)
    * verify a downloaded lib, bin and src distribution (build in the src distribution, preferably
create a release)
    * bump version to prepare for a possible next build
    * update release wiki page
@@ -52, +52 @@

  ==== Prepare the community for a new release ====
  
   1. Announce your intention/desire to have a release on the list
- 
    As new features are added and bugs fixed, it is likely that someone will announce their
intention to produce a release (if they are a committer) and volunteer to be the release manager.
It may also be the case that a non-committer will ask when the next official release will
occur. This should be a sign to committers that there is demand for a release. :)
  
   1. Volunteer as release manager (or try to enlist one)
  
    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. Create wiki pages for the release. (Unless you have already done so. It may be convenient
to have a Wiki page prior to feature freeze and branch cutting). Use pages for a previous
release as a template. You're likely to create a general page and a page to hold the testing
information.
+  1. Create wiki pages for the release. (Unless you have already done so. It may be convenient
to have a wiki page prior to feature freeze and branch cutting). Use pages for a previous
release as a template. You're likely to create a general page and a page to hold the testing
information.
  
   1. [[Anchor(CutBranch)]]For major releases, create a new branch for the release, in both
the code and docs trees.
  
@@ -76, +75 @@

  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.
+   (!) 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.
  
   1. [[Anchor(BranchVersion)]] 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
@@ -86, +85 @@

  }}}
    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.
+   (!) 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.
  
-  1. Add the new branch number to the list of Branches on the source page of the website.
For instructions on how to build the website using Forrest, please see: [http://db.apache.org/derby/papers/derby_web.html]
The actual page to modify is `src/documentation/content/xdocs/dev/derby_source.xml`. For a
minor (bug fix) release, consider bumping the third version of the source tree it will come
off (likely a branch).
+  1. Add the new branch number to the list of branches on the source page of the website.
For instructions on how to build the website using Forrest, please see: [http://db.apache.org/derby/papers/derby_web.html]
The actual page to modify is `src/documentation/content/xdocs/dev/derby_source.xml`. For a
minor (bug fix) release, consider bumping the third version of the source tree it will come
off (likely a branch).
  
  
  ==== Work the toward a release candidate ====

Mime
View raw message