lucene-java-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, 25 Jan 2013 08:02: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 SteveRowe:
http://wiki.apache.org/lucene-java/ReleaseTodo?action=diff&rev1=138&rev2=139

Comment:
Finish modernization

  
  == Website += javadocs ==
  The problem: Lucene's and Solr's voluminous per-release javadocs break the standard CMS
process for the website (i.e., committer commits to the source tree; the CMS buildbot generates
the site, then commits to the staging tree; committer reviews and then publishes to the production
tree), because dynamic website updates, currently scheduled at 21 minutes after the hour on
the hour, interrupt the extremely long commit times for javadocs being staged by buildbot,
resulting in failed commits, caused by conflicts with the dynamic updates: by the time the
buildbot-triggered commit has finished, its svn tree has been rendered stale.
- 
- The solution: skip committing javadocs to the source tree, then staging, then publishing,
and instead commit javadocs directly to the production tree.  Ordinarily this would be problematic,
because the CMS wants to keep the production tree in sync with the staging tree, so anything
it finds  in the production tree that's not in the staging tree gets nuked.  However, the
CMS has a built-in mechanism to allow exceptions to the keep-production-in-sync-with-staging
rule: {{{extpaths.txt}}}.
+ deThe solution: skip committing javadocs to the source tree, then staging, then publishing,
and instead commit javadocs directly to the production tree.  Ordinarily this would be problematic,
because the CMS wants to keep the production tree in sync with the staging tree, so anything
it finds  in the production tree that's not in the staging tree gets nuked.  However, the
CMS has a built-in mechanism to allow exceptions to the keep-production-in-sync-with-staging
rule: {{{extpaths.txt}}}.
  
  {{{extpaths.txt}}} lists paths in the production tree, relative to the project website's
root directory, that are allowed to be out of sync with the staging tree.
  
@@ -168, +167 @@

   1. Add the new version to Wikipedia (english and maybe your own language)
   1. Add the new release to https://freecode.com/ (formerly freshmeat.com)
  
+ = Post-release =
+ 
  == Update JIRA ==
   1. Go to the JIRA "Manage Versions" Administration page (http://issues.apache.org/jira/secure/project/ManageVersions.jspa?pid=12310110)
and click Release for the version you just released. Also 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 JIRA and find all issues that were fixed in the release you just made, whose Status
is Resolved, and do a bulk change to close all of these issues. Uncheck the box that says
"send an email for these changes".
  
+ == 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.  
+ 
+ {{{svn remove}}} old releases, including X.Y-1, from {{{dist/releases/lucene/java/}}} and
{{{dist/releases/lucene/solr/}}}, then {{{svn commit}}}.
+ 
  = See Also =
   * [[http://www.apache.org/dev/release.html|Apache Releases FAQ]]
  

Mime
View raw message