lucene-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Lucene-java Wiki] Update of "ReleaseTodo" by SteveRowe
Date Fri, 13 May 2016 23:18:28 GMT
Dear Wiki user,

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

The "ReleaseTodo" page has been changed by SteveRowe:
https://wiki.apache.org/lucene-java/ReleaseTodo?action=diff&rev1=227&rev2=228

Comment:
Fix the version number update section to reflect the fact that no change id is required anymore.

  
  == Update Version Numbers in the Source Code ==
   1. Add a new version for the next release using the {{{addVersion.py}}} script. If it is
a bugfix release, we will be adding the bugfix version, otherwise we will add the version
to come after the release we are producing.
-   * If a bugfix release, start on the release branch:
+   * If a bugfix release, do the following on the release branch, the stable branch, and
on master:
     * {{{ python3 -u dev-tools/scripts/addVersion.py X.Y.Z }}}
     * {{{ git add -u .; git commit; git push }}}
-    * Using the commit id from the previous commit, run {{{addVersion.py}}} on the stable
branch, adding {{{ --changeid ID }}}
-    * {{{ git add -u .; git commit; git push }}}
-    * Run {{{addVersion.py}}} on trunk, modifying the stable branch command with the new
change id and path to the stable branch checkout.
-    * {{{ git add -u .; git commit; git push }}}
-    * Make sure that the backcompat index for the previous release has been added to the
release branch.  (Note that this will ordinarily *not* have been done if the current release
is {{{X.Y.1}}}, i.e. the first bugfix release off the stable branch.)  See the post-release
section "Generate Backcompat Indexes" below - remember you'll be generating an index for the
*previous* release.
+    * Make sure that the backcompat index for the previous release has been added to the
release branch.  (Note that this will ordinarily '''not''' have been done if the current release
is {{{X.Y.1}}}, i.e. the first bugfix release off the stable branch.)  See the post-release
section "Generate Backcompat Indexes" below - remember you'll be generating an index for the
*previous* release.
-   * If a minor release, start on the stable branch:
+   * If a minor release, you'll be adding the '''next''' minor version, not the version being
released.  Do the following on the stable branch and on master:
     * {{{ python3 -u dev-tools/scripts/addVersion.py X.Y+1.0 }}}
     * {{{ git add -u .; git commit; git push }}}
-    * Using the commit id from the previous commit, run on trunk, adding {{{ --changeid ID
}}}
+   * If a major release, you'll be adding the '''next''' major version, not the version being
released.  Do the following on master:
+    * {{{ python3 -u dev-tools/scripts/addVersion.py X+1.0.0 }}}
+     * The script will print a list of items that need to be done manually for a major release
bump.
     * {{{ git add -u .; git commit; git push }}}
-   * If a major release, only run on trunk:
-    * {{{ python3 -u dev-tools/scripts/addVersion.py X+1.0.0 }}}
-    * The script will print a list of items that need to be done manually for a major release
bump.
-    * {{{ git add -u .; git commit; git push}}}
  
  == Jenkins Release Builds ==
  After the branching is done, add Jenkins task for the release branch so that it runs the
test, like other branches using the instructions on the JenkinsReleaseBuilds page.

Mime
View raw message