Page History

{hide-from:user=*}
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements.  See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License.  You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
{hide-from}

{toc}

h1. Prerequisites
Before entering into this process you need to ensure you will be able to cryptographically sign the final result in such a way that others can validate the signature.  This can be a confusing process.  Here are links to threeseveral documents that should help.
* [http://www.apache.org/dev/openpgp.html]
* [http://www.apache.org/dev/release-signing.html]
* [http://httpd.apache.org/dev/verification.html]

h1. Prepare
In preparation for each release there are a number of sub-steps required to ensure that that the project's repository is in a suitable state for branching.

h2. Update version numbers
(from X.Y.Z-SNAPSHOT to X.Y.Z)

h2. Update CHANGES
Update CHANGES.txt with release date (Release X.Y - MM/dd/yyyy) and (if needed) add additional changelog entries

h2. Update documentation

h2. Commit updates

h1. Build and Test

h2. Perform a clean clone
{code}
git clone https://git-wip-us.apache.org/repos/asf/incubator-knox.git knox-release
{code}

h2. Perform a full build including tests
{code}
cd knox-release
mvn clean package
{code}

h2. Sanity testing
Do some basic manual testing to see if release looks ok.  For example do and install and run through a few of the samples.

h1. Branch
Create a branch for release maintenance

h1. Sign
{code}
ant sign
{code}

h1. Stage - Step-By-Step Guide to Mirroring Releases.

e.g., gpg --armor --output tika-X.Y.tar.gz.asc --detach-sig tika-X.Y.tar.gz \
md5sum tika-X.Y.tar.gz > tika-X.Y.tar.gz.md5

h1. Vote

13. Release Review and Vote: Use the following email as a template for a real email sent to the private@lucene.apache.org and the tika-dev@lucene.apache.org lists, calling for a vote on the release candidate (posted on a publicly accessible website):

h2. Iterate based on feedback until bote passes

h2. Publish
15. Once vote passes, tag the tika release:

svn copy https://svn.apache.org/repos/asf/lucene/tika/trunk \
https://svn.apache.org/repos/asf/lucene/tika/tika/tags/X.Y -m "Tika X.Y release."
16. Copy release tar file to people.apache.org:/www/www.apache.org/dist/lucene/tika. based on vote (also included *.asc file and *.md5 file)

17. Wait 24 hours for release to propagate to mirrors.

h2. Update site
4. Update news in src/site/src/documentation/content/xdocs/index.xml and for main lucene.apache.org site stored at https://svn.apache.org/repos/asf/lucene/site/. The second change may require additional rights

h2. Create version in JIRA for release X.Y.

h2. Send announcements to the user and developer lists.

h3. Prepare for new development

h2. Update version numbers for to A.B-dev (assuming A.B is next release number) in:

pom.xml - version tag
2. Update CHANGES with header for new changes

3. Create version in JIRA for development snapshots (X.Y.Z)

{include:Disclaimer}