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, 12 Mar 2008 19:30:24 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

------------------------------------------------------------------------------
  
    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. For major releases, create a new branch for the release, in both the code and docs trees.
  
    {{{svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/code/trunk/ https://svn.apache.org/repos/asf/db/derby/code/branches/{branchname}/
-m "Created the {branchname} source branch"
  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).
E.g. after bumping from 10.4 to 10.5 `release.properties` should look similar to: 
    {{{#Wed Jul 19 08:21:42 PDT 2006
@@ -73, +74 @@

  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)]]
-  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
+  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
  }}}
    This will set the version string for the branch to 
@@ -84, +84 @@

  
    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. Post to derby-dev requesting that a new version be added to JIRA for the next version
of Derby (this may well have been done earlier).
+  1. Post to derby-dev requesting that new versions be added to JIRA for the beta version
on the branch and the new development version of Derby on trunk (this may well have been done
earlier).
  
-  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`.
+  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).
  
-   For a minor (bug fix) release, consider bumping the third version of the source tree it
will come off (likely a branch).
- 
-  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.
  
  ==== Work the toward a release candidate ====
  
@@ -105, +102 @@

  
    Get to work! Add features, fix bugs, and update STATUS as you go. The wiki is nice, as
are personal webpages, but STATUS is the designated place for Apache projects to keep their
current status. Apache members and committers expect to be able to grab the STATUS file from
the code tree to determine the current status of the project. It's a nice thing to keep the
STATUS file on branches up to date with the current status of the branch. The other essential
document is a document describing the changes. Derby branches up to 10.2 included a file 'CHANGES'
for that purpose; 10.3 branch and trunk have a RELEASE_NOTES.html checked in. RELEASE_NOTES.html
is generated using the generator in <10.3 branch and up/trunk>/java/build/org/apache/derbyBuild/ReleaseNotesGenerator.java,
which is activated by executing ant genrelnotes in tools/release. The CHANGES.html file can
be generated using <10.3 branch and /trunk>/java/build/org/apache/derbyBuild/ChangesFileGenerator.java,
which can be
  activated using ant genchanges in tools/release.
  
-  1. Drive the bug list to zero.
+  1. [[Anchor(DriveBugListToZero)]] Drive the bug list to zero.
  
    As the list of remaining bugs in JIRA approaches zero, be sure to mark their status properly
in JIRA. Mark blocker and critical bugs as such so that others can see the status at a glance.
Move non-showstopper bugs out to future releases if it appears they will not be fixed for
this release.
  
@@ -216, +213 @@

  
    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.
  
- === For each release candidate ===
+ === For each release candidate === [[Anchor(ReleaseCandidate)]]
  
- [[Anchor(ReleaseCandidate)]]
  ==== Check-ins just before generating release artifacts ====
  
-  1. Set the beta property to false. Bump the point (4th digit) if required, and check in
the new version. 
+  1. For the '''first''' release candidate on a branch: Set the beta property to false and
create `maintversion.properties`, and check in the new version of `release.properties`.
  
    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 set the beta property to false 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. 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. E.g. for the ''second'' 10.4 release candidate, `release.properties` would
look something like:
    {{{#Wed Jul 19 08:21:42 PDT 2006

Mime
View raw message