THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- Announce that the vote has passed on the dev mailing list, ideally with subject beginning [RESULT]
- Tag the release from the same revision from which the passing release candidate's was built:
git tag -a releases/lucene-solr/5.5.0 -m "Lucene/Solr 5.5.0 release" 2a228b3920a07f930f7afb6a42d0d20e184a943c git push origin releases/lucene-solr/5.5.0
- Delete the maven artifacts from the staging repo:
svn rm -m "delete the lucene maven artifacts" https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.1.0-RC2-rev.../lucene/maven svn rm -m "delete the solr maven artifacts" https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.1.0-RC2-rev.../solr/maven
- Move the new release artifacts to the release repo:
svn move -m "Move Lucene RC2 to release repo." https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.1.0-RC2-rev.../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-rev.../solr https://dist.apache.org/repos/dist/release/lucene/solr/5.1.0
- Clean up the containing folder on the staging repo:
svn rm -m "Clean up the RC folder" https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.1.0-RC2-rev...
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!
- Publish maven artifacts - in a source checkout do the following (note that this step will prompt you for your Apache LDAP 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 ant clean stage-maven-artifacts -Dmaven.dist.dir=/tmp/releases/6.0.1/lucene-solr-6.0.1-RC2-rev.../solr/maven/ -Dm2.repository.id=apache.releases.https -Dm2.repository.url=https://repository.apache.org/service/local/staging/deploy/maven2
Once you have transferred all maven artifacts to repository.apache.org, you will need to: log in there with your ASF credentials; locate the staging repository containing the release that you just uploaded; "close" the staging repository; wait and wait and keep clicking refresh until it allows you to: and then "release" the staging repository. This will cause them to sync to Maven Central. See here for more details.
- Maven central should show the release after a short while, but you need to wait 24 hours to give the Apache mirrors a chance to copy the new release.
If you wish, use this script to continually check the number and percentage of mirrors (and Maven Central) that have the release: dev-tools/scripts/poll-mirrors.py -version 5.5.0.
Until all Maven mirrors have the release (which could take up to 24 hours), you should see the Lucene-Solr-SmokeRelease-master job fail. While waiting, this is a good time to execute the "Increment the version on the release branch" and "Generate Backcompat Indexes" steps as outlined below. (The latter step might not succeed immediately, due to the source tarball not available through the archive repository, but it will work after 1-2 hours.)
Update Website
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.
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.
For more info, see the following sections in the Apache CMS Reference:
A worked out example: How do I make the mail archives for my TLP accessible through the /mail URL?
Update extpaths.txt
svn co --depth=immediates https://svn.apache.org/repos/asf/lucene/cms/trunk/content website-source ('content' is a very generic name. So, we check it out to a self-explanatory name 'website-source')
cd website-source
Add Lucene javadocs dir: echo core/X_Y_Z >> extpaths.txt
Add Solr javadocs dir: echo solr/X_Y_Z >> extpaths.txt
- Do a sanity check in the extpaths.txt to ensure that the above two lines were added at the end, and they are in their separate lines. This step is needed in case the file didn't have a newline character in the end to begin with, in which case just fix it by introducing a newline before core/X_Y_Z.
svn commit -m "Update CMS production sync exceptions for X_Y_Z javadocs" extpaths.txt
cd ..
rm -rf website-source
Push docs, changes and javadocs to the CMS production tree
- Ensure your refridgerator has at least 2 beers - the svn import operation can take a while, depending on your upload bandwidth. (Data point: on a 5Mbps upload connection, it took me 11 minutes to upload the Lucene docs and 6 minutes to upload the Solr docs. - Steve)
- Checkout the release tag created above and build the release documentation. Be sure to check that the version number is correct before pushing. Example:
git checkout releases/lucene-solr/X.Y.Z ant documentation -Dversion=X.Y.Z svn -m "Add docs, changes and javadocs for Lucene 6.0.1" import <checkoutroot>/lucene/build/docs https://svn.apache.org/repos/infra/websites/production/lucene/content/core/6_0_1 svn -m "Add docs, changes and javadocs for Solr 6.0.1" import <checkoutroot>/solr/build/docs https://svn.apache.org/repos/infra/websites/production/lucene/content/solr/6_0_1 - Confirm you can browse to these URLs manually, and especially that solr javadocs link back to lucene's correctly. Examples:
Update redirect to latest Javadoc
We make it possible to link to latest javadoc by providing redirect links for e.g. http://lucene.apache.org/solr/api/solr-core/ which will auto redirect to whatever is the latest released version, i.e. http://lucene.apache.org/solr/4_3_0/solr-core/ for 4.3.0. This is handled in .htaccess:
Goto CMS root http://lucene.apache.org/
Click on the CMS book marklet on your bookmarks bar. If you have not already installed the bookmark, go to CMS bookmarklet page and search for the link "ASF CMS" and follow the instructions.
Before changing anything here, click [Update this directory] to ensure you are operating on the latest version of the website.
Scroll down to the file .htaccess and click [Edit]
Locate the lines starting with RedirectMatch temp /core|solr/api/... and change the version url component to match X_Y_Z above. One of the RedirectMatch lines will be for the Solr reference guide, and will only have X_Y instead of X_Y_Z. That line should only be updated if a new reference guide is being released at the same time as this release.
Click Submit.
Click Commit, fill in a message and commit your change. No need to publish site yet - that will be done in next chapter.
NOTE As an alternative to CMS online editing, you can checkout the site from SVN and edit/commit .htaccess that way.
Update the rest of the website
NOTE: don't do this until you are ready to go to production. Every hour at :21 (e.g. 8:21, 9:21, ...) buildbot will commit all content from staging to production.
- Once mirrors are ready, use the bookmarklet or whatever to do the minor changes and news blurbs and stuff.
The safest way is to svn checkout https://svn.apache.org/repos/asf/lucene/cms/trunk/ and use find/grep for the previous release, add entries, and then svn commit and look at the staging website (http://lucene.staging.apache.org). Javadocs won't work because they go directly to production (see above) but you can check everything else this way.
Be sure to update the version in content/latestversion.mdtext
Immediately after committing your changes, you should see the CMS buildbot kick off a new build here at https://ci.apache.org/builders/lucene-site-staging After that finishes, you should load http://lucene.staging.apache.org and verify your changes look OK, and iterate if not. Be sure your browser is not caching an old copy!
If for some reason your changes fail to show up at http://lucene.staging.apache.org, try editing a template file, e.g. add harmless whitespace to http://svn.apache.org/repos/asf/lucene/cms/trunk/templates/core-sidebar.html because this could provoke the buildbot into trying harder (do a "clean" build)
Once all is good on staging, publish the site, e.g. by visiting http://lucene.staging.apache.org, invoking the CMS bookmarklet, then clicking the publish link. Or just go straight here: https://cms.apache.org/lucene/publish
Wait for these changes to appear on both of Apache's main webservers (US: http://lucene.us.apache.org, EU: http://lucene.eu.apache.org, http://lucene.apache.org is dependent on your own geographic location, so the other mirror may still be outdated) before doing the next steps (see http://www.apache.org/dev/project-site.html for details on how the site is mirrored to Apache's main web servers). Once they appear, verify all links are correct in your changes!
As of the release of 7.0.1, the following files on the website must be modified (in addition to extpaths.txt which is already covered in previous steps) to include the new release version:
...
TODO: Add Pelican information
Push docs, changes and javadocs to the subversion website production tree
- Ensure your refridgerator has at least 2 beers - the svn import operation can take a while, depending on your upload bandwidth. (Data point: on a 5Mbps upload connection, it took me 11 minutes to upload the Lucene docs and 6 minutes to upload the Solr docs. - Steve)
- Checkout the release tag created above and build the release documentation. Be sure to check that the version number is correct before pushing. Example:
git checkout releases/lucene-solr/X.Y.Z ant documentation -Dversion=X.Y.Z svn -m "Add docs, changes and javadocs for Lucene 6.0.1" import <checkoutroot>/lucene/build/docs https://svn.apache.org/repos/infra/websites/production/lucene/content/core/6_0_1 svn -m "Add docs, changes and javadocs for Solr 6.0.1" import <checkoutroot>/solr/build/docs https://svn.apache.org/repos/infra/websites/production/lucene/content/solr/6_0_1 - Confirm you can browse to these URLs manually, and especially that solr javadocs link back to lucene's correctly. Examples:
Update the project DOAP files
...