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 Sat, 28 May 2016 14:25:36 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=236&rev2=237

Comment:
trunk,master -> "unstable branch"; modernize post-release section; add an example for dropping
old releases from the mirrors

  On dev@lucene.apache.org , decide on:
  
   1. which JIRA issues shall be committed before a release is made; set the appropriate "Fix
Version" in JIRA for these issues
-  1. the date for branching the trunk and the start of the feature freeze phase
+  1. the date for branching from the unstable branch and the start of the feature freeze
phase
   1. the length of the feature freeze phase
   1. a tentative release date
  
@@ -78, +78 @@

  == 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:
-    * Do the following on the release branch, the stable branch, and on master:
+    * Do the following on the release branch, the stable branch, and on the unstable branch:
       * {{{python3 -u dev-tools/scripts/addVersion.py X.Y.Z}}}
       * {{{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, you'll be adding the '''next''' minor version, not the version being
released.  Do the following on the stable branch and on master:
+   * 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 the unstable branch:
     * {{{python3 -u dev-tools/scripts/addVersion.py X.Y+1.0}}}
     * {{{git add -u .; git commit; git push}}}
-   * If a major release, you'll be adding the '''next''' major version, not the version being
released.  Do the following on master:
+   * If a major release, you'll be adding the '''next''' major version, not the version being
released.  Do the following on the unstable branch:
     * {{{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}}}
@@ -97, +97 @@

   1. Send a note to dev@ to inform the committers that the branch has been created and the
feature freeze phase has started. Include Do's and Don'ts for the feature freeze phase:
    * No new features may be committed to the branch.
    * Documentation patches, build patches and serious bug fixes may be committed to the branch.
However, you should submit '''all''' patches you want to commit to Jira first to give others
the chance to review and possibly vote against the patch. Keep in mind that it is our main
intention to keep the branch as stable as possible.
-   * All patches that are intended for the branch should first be committed to trunk, merged
into the minor release branch, and then into the current release branch.
+   * All patches that are intended for the branch should first be committed to the unstable
branch, merged into the stable branch, and then into the current release branch.
-   * Normal trunk and minor release branch development may continue as usual. However, if
you plan to commit a big change to the trunk while the branch feature freeze is in effect,
think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch
may become more difficult.
+   * Normal unstable and stable branch development may continue as usual. However, if you
plan to commit a big change to the unstable branch while the branch feature freeze is in effect,
think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch
may become more difficult.
    * '''Only''' Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release
candidate build.
  
  = Add New JIRA Versions =
-  1. Go to the JIRA "Manage Versions" Administration pages (https://issues.apache.org/jira/plugins/servlet/project-config/LUCENE/versions
and https://issues.apache.org/jira/plugins/servlet/project-config/SOLR/versions) and add a
new (unreleased) version for the next release on the trunk (for a major release) or branch
(for a minor release).
+  1. Go to the JIRA "Manage Versions" Administration pages (https://issues.apache.org/jira/plugins/servlet/project-config/LUCENE/versions
and https://issues.apache.org/jira/plugins/servlet/project-config/SOLR/versions) and add a
new (unreleased) version for the next release on the unstable branch (for a major release)
or the stable branch (for a minor release).
  
  = Run Tests =
   1. Check out the branch with: {{{git clone https://git-wip-us.apache.org/repos/asf/lucene-solr.git
lucene-solr; cd lucene-solr; git fetch upstream branch_5_5; git checkout branch_5_5}}}
@@ -185, +185 @@

  svn move -m "Move Lucene RC2 to release repo." https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.1.0-RC2-rev1672403/lucene
https://dist.apache.org/repos/dist/release/lucene/java/5.1.0
  svn move -m "Move Solr RC2 to release repo." https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.1.0-RC2-rev1672403/solr
https://dist.apache.org/repos/dist/release/lucene/solr/5.1.0
  }}}
-  1. Note at this point you will see the Jenkins job "Lucene-Solr-SmokeRelease-trunk" begin
to fail, until you run the "Generate Backcompat Indexes" steps below!
+  1. Note at this point you will see the Jenkins job "Lucene-Solr-SmokeRelease-master" begin
to fail, until you run the "Generate Backcompat Indexes" steps below!
   1. Publish maven artifacts - from the {{{lucene/}}} directory in a source checkout (note
that this step will prompt you for your apache credentials):
   {{{
  ant clean stage-maven-artifacts -Dmaven.dist.dir=/tmp/releases/6.0.1/lucene-solr-6.0.1-RC2-rev.../lucene/maven/
-Dm2.repository.id=apache.releases.https -Dm2.repository.url=https://repository.apache.org/service/local/staging/deploy/maven2
@@ -282, +282 @@

  == Generate Backcompat Indexes ==
  After each version of Lucene is released, compressed CFS and non-CFS indexes created with
the newly released version are added to {{{lucene/backwards-codecs/src/test/org/apache/lucene/index/}}},
for use in testing backward index compatibility via {{{org.apache.lucene.index.TestBackwardsCompatibility}}},
which is also located under the {{{backwards-codecs/}}} module.  These indexes are created
via methods on {{{TestBackwardsCompatibility}}} itself - see comments in the source for more
information.
  
- There is a script ({{{dev-tools/scripts/addBackcompatIndexes.py}}}) that automates most
of the process: it downloads the source for the specified release; generates indexes for the
current release using {{{TestBackwardsCompatibility}}}; compresses the indexes and places
them in the correct place in the source tree; modifies {{{TestBackwardsCompatibility.java}}}
to include the generated indexes in the list of indexes to test; and then runs {{{TestBackwardsCompatibility}}}.
 Run this script on the stable branch and on trunk, and if the current release is a bugfix
release, also on the release branch.  On each branch, after running the script, {{{git add}}}
the generated indexes, then {{{cd lucene/backwards-codecs}}} and run {{{ant test -Dtestcase=TestBackwardsCompatibility}}}
and make sure passes before running {{{git commit}}} and {{{git push}}}.
+ There is a script ({{{dev-tools/scripts/addBackcompatIndexes.py}}}) that automates most
of the process: it downloads the source for the specified release; generates indexes for the
current release using {{{TestBackwardsCompatibility}}}; compresses the indexes and places
them in the correct place in the source tree; modifies {{{TestBackwardsCompatibility.java}}}
to include the generated indexes in the list of indexes to test; and then runs {{{TestBackwardsCompatibility}}}.
 Run this script on the stable branch and on the unstable branch, and if the current release
is a bugfix release, also on the release branch.  On each branch, after running the script,
{{{git add}}} the generated indexes, then {{{cd lucene/backwards-codecs}}} and run {{{ant
test -Dtestcase=TestBackwardsCompatibility}}} and make sure passes before running {{{git commit}}}
and {{{git push}}}.
  
- {{{TestBackwardsCompatibility}}} will not test indexes for {{{Version.LATEST}}}, and will
fail if it finds indexes from that version, so before you run {{{addBackcompatIndexes.py}}},
make sure {{{dev-tools/scripts/addVersion.py}}} has been run with the next version to be released
on each of the branches - see item #3, about adding a new version, in the [[#Branching_.26_Feature_Freeze|Branching
& Feature Freeze]] section, above.  This will likely only be an issue on the release branch,
if the current release is a bugfix release, since {{{addVersion.py}}} will have already been
run on the stable branch and on trunk '''before''' the release process has gotten to this
point.
+ {{{TestBackwardsCompatibility}}} will not test indexes for {{{Version.LATEST}}}, and will
fail if it finds indexes from that version, so before you run {{{addBackcompatIndexes.py}}},
make sure {{{dev-tools/scripts/addVersion.py}}} has been run with the next version to be released
on each of the branches - see item #3, about adding a new version, in the [[#Branching_.26_Feature_Freeze|Branching
& Feature Freeze]] section, above.  This will likely only be an issue on the release branch,
if the current release is a bugfix release, since {{{addVersion.py}}} will have already been
run on the stable branch and on the unstable branch '''before''' the release process has gotten
to this point.
  
  To print the script's usage, run it with the {{{--help}}} option: {{{python3 -u dev-tools/scripts/addBackcompatIndexes.py
--help}}}
  
  The script uses a scratch directory - {{{/tmp/lucenebwc/}}} by default if you don't specify
{{{--temp-dir DIR}}} - to store the source for the current release that it downloads, along
with the generated indexes.  This directory will be removed by the script unless you specify
the {{{--no-cleanup}}} option, which is useful when running the script on multiple branches;
in the example below, the {{{--no-cleanup}}} option is included on the non-final script invocations,
but not on the final invocation, so that the scratch directory will be cleaned up after it's
no longer needed.
  
- Here's an example for the 5.1.0 release:
+ Here's an example for the 6.0.0 release:
  
  {{{
- # If this were a bugfix release, e.g. 5.1.1, on the release branch we would first run addVersion.py
+ # If this were a bugfix release, e.g. 6.0.1, on the release branch we would first run addVersion.py
- # if version 5.1.2 has not yet been added, and then addBackcompatIndexes.py:
+ # if version 6.0.2 has not yet been added, and then addBackcompatIndexes.py:
  #
- #    cd /path/to/lucene/dev/branches/lucene_solr_5_1
+ #    cd /path/to/lucene/working/tree
+ #    git checkout branch_6_0
  #    git pull && git status   # Make sure there are no uncommitted changes
- #    java7    # aliased to: export JAVA_HOME="$JAVA7_HOME" ; export PATH="$JAVA7_HOME/bin:$PATH"
  #    ant clean
- #    python3 -u dev-tools/scripts/addVersion.py 5.1.2  # Add the next version after the
current release
+ #    python3 -u dev-tools/scripts/addVersion.py 6.0.2  # Add the next version after the
current release
  #    git add -u .
- #    git commit -m "Add version 5.1.2"
+ #    git commit -m "Add version 6.0.2"
  #    git push
- #    python3 -u dev-tools/scripts/addBackcompatIndexes.py --no-cleanup 5.1.1
+ #    python3 -u dev-tools/scripts/addBackcompatIndexes.py --no-cleanup 6.0.1
- #    git add lucene/backward-codecs/src/test/org/apache/lucene/index/index.5.1.1-*.zip
+ #    git add lucene/backward-codecs/src/test/org/apache/lucene/index/index.6.0.1-*.zip
  #    git status # Look for pending mods to TestBackwardsCompatibility.java and adds of the
generated indexes
  #    git add lucene/backward-codecs/src/test/org/apache/lucene/index/TestBackwardsCompatibility.java
- #    git commit -m "Add 5.1.1 back compat test indexes"
+ #    git commit -m "Add 6.0.1 back compat test indexes"
  #    git push
  #
- # Then also execute all the commands below, substituting 5.1.1 where it says 5.1.0.
+ # Then also execute all the commands below, substituting 6.0.1 where it says 6.0.0.
  
- cd /path/to/lucene/dev/branches/branch_5x
+ cd /path/to/lucene/working/tree
+ git checkout branch_6x
  git pull && git status   # Make sure there are no uncommitted changes
- java7     # aliased to: export JAVA_HOME="$JAVA7_HOME" ; export PATH="$JAVA7_HOME/bin:$PATH"
  ant clean
- python3 -u dev-tools/scripts/addBackcompatIndexes.py --no-cleanup 5.1.0
+ python3 -u dev-tools/scripts/addBackcompatIndexes.py --no-cleanup 6.0.0
- git add lucene/backward-codecs/src/test/org/apache/lucene/index/index.5.1.0-*.zip
+ git add lucene/backward-codecs/src/test/org/apache/lucene/index/index.6.0.0-*.zip
  git status # Look for pending mods to TestBackwardsCompatibility.java and adds of the generated
indexes
  git add lucene/backward-codecs/src/test/org/apache/lucene/index/TestBackwardsCompatibility.java
- git commit -m "Add 5.1.0 back compat test indexes"
+ git commit -m "Add 6.0.0 back compat test indexes"
  git push
  
- cd /path/to/lucene/dev/trunk
+ cd /path/to/lucene/working/tree
+ git checkout master
  git pull && git status   # Make sure there are no uncommitted changes
- java8     # aliased to: export JAVA_HOME="$JAVA8_HOME" ; export PATH="$JAVA8_HOME/bin:$PATH"
  ant clean
- python3 -u dev-tools/scripts/addBackcompatIndexes.py 5.1.0
+ python3 -u dev-tools/scripts/addBackcompatIndexes.py 6.0.0
- git add lucene/backward-codecs/src/test/org/apache/lucene/index/index.5.1.0-*.zip
+ git add lucene/backward-codecs/src/test/org/apache/lucene/index/index.6.0.0-*.zip
  git status # Look for pending mods to TestBackwardsCompatibility.java and adds of the generated
indexes
  git add lucene/backward-codecs/src/test/org/apache/lucene/index/TestBackwardsCompatibility.java
- git commit -m "Add 5.1.0 back compat test indexes"
+ git commit -m "Add 6.0.0 back compat test indexes"
  git push
  }}}
  == Update JIRA ==
   1. Go to the JIRA "Manage Versions" Administration pages (https://issues.apache.org/jira/plugins/servlet/project-config/LUCENE/versions
and https://issues.apache.org/jira/plugins/servlet/project-config/SOLR/versions). Next to
the version you'll release, click the gear pop-up menu icon and choose "Release".  It will
ask you for the release date -- enter it.  It will give the option of transitioning issues
marked fix-for the released version to the next version, but do '''not''' do this as it will
send an email for each issue -- we'll address that separately.
-  1. Go to JIRA search in both Solr and Lucene and find all issues that were fixed in the
release you just made, whose Status is Resolved.  This URL may work (but edit the fixVersion
part): (https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+status=Resolved+AND+fixVersion=4.10.1).
 Do a bulk change (Under Tools... menu) to close all of these issues (this is a workflow transition
task). Uncheck the box that says "send an email for these changes".
+  1. Go to JIRA search in both Solr and Lucene and find all issues that were fixed in the
release you just made, whose Status is Resolved.  This URL may work (but edit the fixVersion
part): (https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+status=Resolved+AND+fixVersion=6.0.1).
 Do a bulk change (Under Tools... menu) to close all of these issues (this is a workflow transition
task). Uncheck the box that says "send an email for these changes".
-  1. Do another JIRA search in both Solr and Lucene to find all issues with Unresolved Resolution
and fixVersion of the release you just made, and do a bulk change to the fixVersion to be
both the trunk version and the next version on the branch you just released from.  Uncheck
the box that says "send an email for these changes".
+  1. Do another JIRA search in both Solr and Lucene to find all issues with Unresolved Resolution
and fixVersion of the release you just made (this URL may work - but edit the fixVersion part
- https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+resolution=Unresolved+AND+fixVersion=6.0.1),
and do a bulk change to the fixVersion to be both the master version and the next version
on the branch you just released from.  Uncheck the box that says "send an email for these
changes".
   1. Add a new Version for the next possible release version on the "Manage Versions" Administration
page (https://issues.apache.org/jira/plugins/servlet/project-config/LUCENE/versions). e.g.
If the current release is 5.2.1, add 5.2.2 with a description so that contributors can commit
to the release branch with the next release version. In case of a minor release e.g. 5.2,
this step needs to be done when the new release branch is cut.
  
  == Don't mirror old releases ==
- Shortly after new releases are first mirrored, they are copied to the archives.  Only the
latest point release from each active branch should be kept under the Lucene PMC svnpubsub
area {{{dist/releases/lucene/}}}.  Older releases can be safely deleted from {{{dist/releases/lucene/}}},
since these releases are already backed up in the archives.
+ Shortly after new releases are first mirrored, they are automatically copied to the archives.
 Only the latest point release from each active branch should be kept under the Lucene PMC
svnpubsub area {{{dist/releases/lucene/}}} and {{{dist/releases/solr/}}}.  Older releases
can be safely deleted, since they are already backed up in the archives.
  
- {{{svn remove}}} old releases, including X.Y-1, from {{{dist/releases/lucene/java/}}} and
{{{dist/releases/lucene/solr/}}}, then {{{svn commit}}}.
+ Here's an example for the 6.0.1 release (note that the 5.5.1 release is not removed):
+ 
+ {{{
+ $ svn list https://dist.apache.org/repos/dist/release/lucene/java
+ 5.3.1/
+ 5.3.2/
+ 5.4.1/
+ 5.5.0/
+ 5.5.1/
+ 6.0.0/
+ 6.0.1/
+ KEYS
+ README.html
+ 
+ $ svn rm -m "Stop mirroring old releases" https://dist.apache.org/repos/dist/release/lucene/java/{5.3.1,5.3.2,5.4.1,5.5.0,6.0.0}
+ 
+ Committed revision 13826.
+ 
+ $ svn list https://dist.apache.org/repos/dist/release/lucene/solr
+ 4.10.4/
+ 5.2.0/
+ 5.2.1/
+ 5.3.0/
+ 5.3.1/
+ 5.3.2/
+ 5.4.1/
+ 5.5.0/
+ 5.5.1/
+ 6.0.0/
+ 6.0.1/
+ HEADER.html
+ KEYS
+ ref-guide/
+ 
+ $ svn rm -m "Stop mirroring old releases" https://dist.apache.org/repos/dist/release/lucene/solr/{4.10.4,5.2.0,5.2.1,5.3.0,5.3.1,5.3.2,5.4.1,5.5.0,6.0.0}
+ 
+ Committed revision 13827.
+ }}}
  
  == Update WIKI ==
  The Solr WIKI has a page for every version which is often linked to from WIKI pages to indicate
differences between versions, example: http://wiki.apache.org/solr/Solr4.3. Do the following:

Mime
View raw message