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 "ReleaseCandidates" by RichardHillegas
Date Mon, 18 Oct 2010 21:09:10 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The "ReleaseCandidates" page has been changed by RichardHillegas.
http://wiki.apache.org/db-derby/ReleaseCandidates?action=diff&rev1=1&rev2=2

--------------------------------------------------

  
  For each release candidate:
  
+  1. Prepare the code and documentation.
+ 
    * drive bug list to zero
-   * add new section to testing wiki pages
+   * add a new section to testing wiki pages
    * arrange for appropriate version numbers in JIRA
    * ensure all new (and old) files have correct copyright & license
+   * update `releaseSummary.xml`
+   * ensure all release notes are current
+   * generate `RELEASE_NOTES.html` in the branch and check it into the svn repository. Please
consult the instructions for [[http://wiki.apache.org/db-derby/ReleaseNoteProcess|generating
release notes]].
+ 
+  1. If you are building a 10.7 or later release, build the release distributions by executing
the "release" target in the top level build.xml file. Skip the step which follows--the master
build target preforms all of the work described in the following step.
+ 
+  1. If, however, you are building a 10.6 or earlier release, perform the following steps:
+ 
    * svn update source and doc trees
    * build all, then: 
-   * ensure all release notes are current
    * copy `rrefexcept71493.dita` from `<source>/classes/doc` to `<docsource>/src/ref`
-   * update `releaseSummary.xml`, create release notes & changes files
    * clean doc & source trees, then build release artifacts
+   * sign your release artifacts
+   * bump version to prepare for a possible next build
+ 
+  1. After building the release distributions:
+ 
    * (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`)
+   * copy the release artifacts to `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
    * call for vote
  
- <<Anchor(FirstRC)>>
- === For the first release candidate on a new branch ===
- 
-  1. Update `tools/ant/properties/release.properties` by hand, and set the `beta` property
to false (unless this is a ''beta'' release candidate).
-  1. Check in the modification.
-  1. You will need to clobber and build again before you can see the changed `beta` property
reflected in the source. Note that the first release off a new branch is automatically beta,
even if you set the `beta` property to false.
  
  <<Anchor(ForEachRC)>>
  === For each release candidate ===
  
  Verify that:
-  * `beta` property is false (unless you are creating a ''beta'' release candidate). If this
is the first release candidate off this branch the `beta` property should have been set to
false in a [[#FirstRC|previous section]].  If this is an update relase, the `beta` property
should have been set to false as a part of the release cycle for the first release off this
branch. 
-  * Version number is correct. For the first release candidate off a branch, the version
number should have been set immediately [[#BranchVersion|after cutting the branch]]. For subsequent
release candidates, including update release candidates, the version number should have been
bumped after [[#Bump4th|spinning the previous release candidate]]
+  * `beta` property is false (unless you are creating a ''beta'' release candidate). If this
is the first release candidate off this branch the `beta` property will have been set to false.

+  * Version number is correct. On the 10.6 and earlier branches, the version number should
have been bumped after spinning the previous release candidate.
  
- The third and fourth parts of the version number are combined into a single property, maint,
where maint = (third digit * 1000000) + fourth digit. 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. 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. 
+ You may need to worry about the following arcana if you are building a release on a 10.6
or earlier branch: The third and fourth parts of the version number are combined into a single
property, maint, where maint = (third digit * 1000000) + fourth digit. 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. Fixpack (3rd digit) will normally
be set to 1 when the branch is cut, but if it isn't, it must be incremented before the release
candidate can be created. 
  
  ==== Check-ins just before generating release artifacts ====
  
+ You may skip this section if you are building a 10.7 or later release. The work described
in this section is performed by the master "release" target in the top level 10.7 build.xml
file.
+ 
-  1. [[http://db.apache.org/derby/manuals/docscheck.html|Adjust version numbers in documentation]].
Make sure the copyright notices has the correct years. 
+  1. For releases on the 10.6 or earlier branches, [[http://db.apache.org/derby/manuals/docscheck.html|Adjust
version numbers in documentation]]. Make sure the copyright notices has the correct years.

- 
-  1. Generate `RELEASE_NOTES.html` in the branch and check it into the svn repository. Please
consult the instructions for [[http://wiki.apache.org/db-derby/ReleaseNoteProcess|generating
release notes]].
  
   1. For versions < 10.3; finalize `CHANGES`. For later releases the `CHANGES` file has
been deprecated.
   
@@ -59, +65 @@

    'svn up' in your subversion view to bring all files in your view up to the latest revision.
Otherwise, the version output by svn which is captured for the build number will be a range
(e.g. 290275:320938).
  
  ==== Build the release artifacts ====
+ 
+ You may skip this section too if you are building a 10.7 or later release. The work described
in this section is performed by the master "release" target in the top level 10.7 build.xml
file. for 10.7 or later, all you have to do is invoke the "release" target and answer the
questions it poses.
  
   1. Check you have all required pieces:
  	- doc tree
@@ -178, +186 @@

  
    And comparing the output of openssl to the output from ant in `db-derby-10.1.1.0-src.zip.md5`
  
+  1. <<Anchor(Bump4th)>>Bump the fourth digit of the source in preparation for
a possible next build. I don't think this step does anything except update the last digit
of the release id in release.properties. The bumped release id represents the head of the
branch.
+ 
+   {{{
+ cd tools/release
+ ant bumplastdigit}}}
+ 
+   Commit the changed version number.
+   
+ 
+ ==== Post the release artifacts ====
+  
   1. Keep the `jars/insane/*.jar` and `jars/insane/derby.war` files available. You will need
them for maven deployment after the vote is complete.
    (!) It is advisable to copy the jars to another directory and include the version number
of the release candidate in the directory name. This way you avoid having to extract the jars
from the release artifacts if you inadvertently overwrite the jars (through a rebuild) before
deploying to the maven repository.
  
+  1. Add the next release id to JIRA. This is the release id on the branch. For 10.6 and
earlier releases, you will have bumped this id by hand. For 10.7 releases and later, the id
will have been bumped by the master "release" target. This allows bugs to be marked as fixed
at the head of the branch. See the following email thread for our latest thinking on this
topic: http://old.nabble.com/Re%3A-Plans-for-a-10.5.3.1--tt26533770.html#a26577283
-  1. <<Anchor(Bump4th)>>Bump the fourth digit of the source in preparation for
a possible next build. I don't think this step does anything except update the last digit
of the release id in release.properties. The bumped release id represents the head of the
branch.
- 
-   {{{
- cd tools/release
- ant bumplastdigit}}}
- 
-   Commit the changed version number.
-   
-  
-  1. At the same time, make sure that you add the bumped release id to JIRA. This allows
bugs to be marked as fixed at the head of the branch. See the following email thread for our
latest thinking on this topic: http://old.nabble.com/Re%3A-Plans-for-a-10.5.3.1--tt26533770.html#a26577283
  
   1. Post the distributions
     a. Make sure the umask of your Apache account grants both read and write access to group
(db) and only read access to others. {i} Read access for others is necessary  for web access,
and the write permission for the db group will make life easier for future release managers.
 
     a. Create a new directory for the release candidate in your `people.apache.org:public_html`
directory.
-    a. Upload all files from the `tools/release` directory into this directory.
-    a. Upload `snapshot/derby_core_plugin_x.y.z.rev.*` into this directory.
+    a. For 10.7 and later releases, upload to this directory all of the artifacts in release/distributions.
+    a. For 10.6 and earlier releases, upload all files from the `tools/release` directory
and `snapshot/derby_core_plugin_x.y.z.rev.*`
     a. (Optional:) Upload `derby_ui_plugin_a.b.c.*` into this directory. 
      {i} If someone has volunteered to build the Eclipse plugin for you, you will have to
defer this step until the volunteer has had a chance to download the other release artifacts
which she will need to build the plugin. 
  

Mime
View raw message