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 "TmpDerbySnapshotOrRelease" by MyrnavanLunteren
Date Tue, 24 Jul 2007 18:38:32 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 MyrnavanLunteren:
http://wiki.apache.org/db-derby/TmpDerbySnapshotOrRelease

------------------------------------------------------------------------------
  
  == Releases ==
  
+ === communicate with the community ===
   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 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. Vote on the distributions
+ 
+   Call for a vote on derby-dev to have the distributions posted on your public_html accepted
for the release. A vote needs to be running for at least 7 days, so, give at least that much
time before closing the vote to give adequate time for others to inspect and test the distributions.
If no-one has responded after a week, prod gently until you get a response. A majority of
votes, and at least one binding +1 vote are required for acceptance.
+ 
+   Forward or bcc a copy of the call for vote to private@db.apache.org so the DB PMC is aware
that a vote is in progress. Also forward the results post to private@db.apache.org. (Note:
do not '''cc''' the PMC; '''bcc''' or forward a copy of the post.)
+ 
+  1. Address items on the ReleaseVettingChecklist
+ 
+   Make sure that the community addresses relevant items on the ReleaseVettingChecklist.
+ 
+  1. If vote does not pass and go back to 'Drive bug list to zero'.
+ 
+   If the vote does not pass and additional release candidates need to be made, then presumably
it won't have passed because of a showstopper-type bug or similar issue. So, go back to the
bug-fixing section.
+ 
+ 
+ 
+ === herding bugs, changes, fixes, release notes ===
  
   1. Target the bugs you feel should be fixed in JIRA
  
@@ -32, +51 @@

      - fixed in the release under study but not in the previous release
      - marked with 'Existing Application Impact' or 'Release Note Needed'.
  
-  1. Check that all creative works have ASF license headers. See: [http://wiki.apache.org/db-derby/FixingLicenseHeader].
Also ensure that the year in NOTICE is correct.
+  1. Check that all creative works have ASF license headers. See: [http://wiki.apache.org/db-derby/FixingLicenseHeader].
Also ensure that the year in NOTICE is correct. Similarly, ensure that all versions and copyright
details in the docs tree are correct, this includes the top level conrefs.dita, as well as
lower level dita files.
  
  
+ === prepare your machine/environment for building the release artifacts ===
   1. Make sure your public PGP/GPG key is in the KEYS file
  
    For information about PGP and why it is used to sign release binaries at Apache, please
read [http://people.apache.org/~henkp/trust/].
@@ -101, +121 @@

  
   1. Create the release distributions and checksums, sign the distributions
  
-   Check your classpath for osgi.jar for OSGI support and make sure jsr169compile.classpath
is set for J2ME support. For 10.2 forward, make sure that you have JDK 1.6 available and that
you've set the jdk16 property to the JAVA_HOME for your JDK 1.6 installation in your ant.properties
so that the JDBC 4.0 classes are built and the JDBC 4.0 javadoc is created. If you have the
sane property set in your ant.properties, remove it at this time to prevent it from overriding
the false setting passed into the snapshot target. Create the distributions for release by
running:
+   Check your classpath for osgi.jar for OSGI support and make sure jsr169compile.classpath
is set for J2ME support. For 10.2 forward, make sure that you have JDK 1.6 available and that
you've set the jdk16 property to the JAVA_HOME for your JDK 1.6 installation in your ant.properties
so that the JDBC 4.0 classes are built and the JDBC 4.0 javadoc is created. If you have the
sane property set in your ant.properties, remove it at this time to prevent it from overriding
the false setting passed into the snapshot target.
+ 
+ === building the release artifacts ===
+ 
+ 1. Create the distributions for release by running:
  
    {{{svn up
  ant clobber
@@ -184, +208 @@

  
    Copy the files from tools/release to your public_html directory on people.apache.org.
Post to derby-dev so that others can begin testing.
  
-  1. Vote on the distributions
  
+ === publicise new release ===
-   Call for a vote on derby-dev to have the distributions posted on your public_html accepted
for the release. A vote needs to be running for at least 7 days, so, give at least that much
time before closing the vote to give adequate time for others to inspect and test the distributions.
If no-one has responded after a week, prod gently until you get a response. A majority of
votes, and at least one binding +1 vote are required for acceptance.
- 
-   Forward or bcc a copy of the call for vote to private@db.apache.org so the DB PMC is aware
that a vote is in progress. Also forward the results post to private@db.apache.org. (Note:
do not '''cc''' the PMC; '''bcc''' or forward a copy of the post.)
- 
-  1. Address items on the ReleaseVettingChecklist
- 
-   Make sure that the community addresses relevant items on the ReleaseVettingChecklist.
- 
-  1. If vote does not pass and go back to 'Drive bug list to zero'.
- 
-   If the vote does not pass and additional release candidates need to be made, then presumably
it won't have passed because of a showstopper-type bug or similar issue. So, go back to the
bug-fixing section.
  
   1. If the vote passes, put distributions onto mirrors
  

Mime
View raw message