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, 29 Apr 2008 17:33:53 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

------------------------------------------------------------------------------
  
    To build the documentation, you need to obtain DITA-OT1.1.2.1_bin-ASL.zip and place it
in the docs' tree lib. See: [http://db.apache.org/derby/manuals/dita.html] for more info about
building the documentation.
  
+  1. (Optional:) Have eclipse installed or make arrangements with someone willing to build
the eclipse ui plugin. As release manager you need to have access to the plugin zips if you
don't build them yourself (e.g. the volunteer can attach the plugin zips to a Jira issue).
+ 
  [[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.
+  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.
  
@@ -224, +226 @@

  === For each release candidate ===
  
  Verify that:
-  * `beta` property is false. 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. 
+  * `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]
  
  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. 
@@ -260, +262 @@

  
  	- `ant.properties` set correctly for: jdk15, jdk16, jsr169
  
- 	- sane not set in ant.properties /!\ ''' Is this still true?'''
+ 	- sane not set in ant.properties
  
  	- non-source files for building source available: `junit.jar`, `felix.jar`, (with 10.3
and earlier: `osgi.jar`), dita library (again).
   
@@ -284, +286 @@

  ant release
  ant sign}}}
  
-   You will need to enter your PGP passphrase several times as the release distributions
are signed. This will create the following files in your tools/release directory:
+   You will need to enter your PGP passphrase several times as the release distributions
are signed. (''Note that you can save yourself some typing by using gpg's `--pasphrase-fd
<fd>` option. This instructs gpg to read the passphrase from the specified file descriptor'').
+ 
+   This will create the following files in your tools/release directory:
  
     *db-derby-[version]-bin.tar.gz
     *db-derby-[version]-bin.zip
@@ -295, +299 @@

     *db-derby-[version]-src.tar.gz
     *db-derby-[version]-src.zip
  
-   The Eclipse core plugin is generated in the snapshot directory at the top level by the
snapshot target. You should also create the Eclipse UI plugins (see plugins/eclipse/readme.txt,
except use the core plugin created in the snapshot directory), but this requires Eclipse.
If you don't want to do it yourself, those interested in the Eclipse plugins will likely volunteer
to generate them for you. You should also create checksums and signatures for these files
with:
+   The Eclipse core plugin is generated in the snapshot directory at the top level by the
snapshot target. You should also create the Eclipse UI plugins (see `plugins/eclipse/readme.txt`,
except use the core plugin created in the snapshot directory), but this requires Eclipse.
If you don't want to do it yourself, those interested in the Eclipse plugins will likely volunteer
to generate them for you. 
+ 
+   /!\ Note that ui-plugin can be built as a ''beta''. If you don't build the ui-plugin yourself,
make sure that its ''beta'' status matches that of the release candidate you are building.

+ 
+   You should also create checksums and signatures for these files with:
  
    {{{gpg --armor --detach-sign derby_ui_plugin_[version].zip
  gpg --armor --detach-sign derby_core_plugin_[version].zip

Mime
View raw message