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 MikeMcCandless
Date Thu, 11 Feb 2016 08:56:58 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 MikeMcCandless:
https://wiki.apache.org/lucene-java/ReleaseTodo?action=diff&rev1=204&rev2=205

Comment:
some svn -> git switches

  = Branching & Feature Freeze =
  == Branching ==
   1. Run {{{ant precommit}}} to run a bunch of sanity & quality checks, then fix any
problems that are found.
-  1. For the first release in a minor release series - i.e. X.Y.0 - create a minor release
branch off the current major version branch, e.g. for minor release 4.2:
+  1. For the first release in a minor release series - i.e. X.Y.0 - create a minor release
branch off the current major version branch, e.g. for minor release 5.5:
   {{{
- svn copy https://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x \
- https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_1 -m "Starting Lucene/Solr
5.1 branch."
+ git clone https://git-wip-us.apache.org/repos/asf/lucene-solr.git lucene-solr
+ cd lucene-solr
+ git checkout branch_5x
+ git checkout -b branch_5_5
+ git push upstream branch_5_5
  }}}
  
  == 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:
     * {{{ python3 -u dev-tools/scripts/addVersion.py X.Y.Z }}}
-    * {{{ svn commit }}}
+    * {{{ 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 --downstream-repo /path/to/release/branch/checkout}}}
-    * {{{ svn commit }}}
+    * {{{ 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.
-    * {{{ svn commit }}}
+    * {{{ 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.
    * If a minor release, start on the stable branch:
     * {{{ python3 -u dev-tools/scripts/addVersion.py X.Y+1.0 }}}
-    * {{{ svn commit }}}
+    * {{{ git add -u .; git commit; git push }}}
     * Using the commit id from the previous commit, run on trunk, adding {{{ --changeid ID
--downstream-repo /path/to/stable/branch/checkout}}}
-    * {{{ svn commit }}}
+    * {{{ 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.
-    * {{{ svn commit}}}
+    * {{{ 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