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 several 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

Discuss

Send a [DISCUSS] email to the dev@knox list proposing a release.

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.

Start with clean local repo

This can be a fresh clone or just a repo that has no pending changes or extraneous files in.

Switch to the branch that you will branch from

In this step we need to check out the previous release branch or some other existing branch from which we will create our new one.

List existing branches:

git branch -al

* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/v0.2.0
  remotes/origin/v0.3.0
  remotes/origin/v{X.Y.Z-1}

Check out the previous (release) branch:

git checkout -t origin/v{X.Y.Z-1}

Tag Branch Point and Branch

This step tags the point in time of when the branching starts within the remote repo.

git tag --annotate v{X.Y.Z}-branch --message "Branch point for v{X.Y.Z}"
git push origin --tags

Switch to the new branch

Check out the branch that is intended for this release:

git checkout -b v{X.Y.Z}
git push --set-upstream origin v{X.Y.Z}

Clone & Checkout Branch

This step does a couple things for us:

• it ensures that the branch is actually there and available
• it ensures that our local repository to work from is clean

git clone https://git-wip-us.apache.org/repos/asf/incubator-knox.git knox-{X.Y.Z}
cd knox-{X.Y.Z}
git checkout -t origin/v{X.Y.Z}
git pull

Cherry pick previous commits from master

You can use cherry-pick to pull commits in from existing branches.

To pull the changeset for the commit at the tip of the master branch:

git cherry-pick origin/master

Search for and replace all occurrences of the previous branch versions within the project's files

All build artifacts that contain the previous branch's version need to be updated with the new version to reflect this new branch.

grep -r "0\.3\.0" .

Change all occurrences as appropriate.

Update version numbers on master branch (from A.B.C-SNAPSHOT to D.E.F-SNAPSHOT) and push changes

Update version numbers on release branch (from A.B.C-SNAPSHOT to A.B.C) and push changes

Update CHANGES

Update CHANGES with release date (Release X.Y - MM/dd/yyyy) and (if needed) add additional changelog entries.
The CHANGES file can be found in gateway-release/home

Update documentation

Build, Test and Push Changes

git pull
git commit --all --message "Updating branch."
ant verify
git push

Create a new Jenkins job to build the release. It should call these two commands. It is probably best to copy the previous releases job.

Assuming that you have proper karma for creating new Jenkins jobs, you will see a link to create a new one.
From that link you will be provided a page to select how to proceed; select copy existing job.

Ensure that the following form reflects the following values within various form elements:

• maven
• -Prelease clean install
• ant post-build

Be sure to change any versions to reflect v

ant download-candidate

ant sign-candidate

cd release

src.zip.asc knox

.zip.asc knox-

Verify the SHA-1 hashes for both the source and binary distribution.  _Note: This assumes a Linux or MacOS environment with openssl installed._

src.zip.sha && openssl sha1 knox

.zip.sha && openssl sha1 knox-

Verify the MD5 digest for both the source and binary distribution.  _Note: This assumes a Linux or MacOS environment with openssl installed._

src.zip.md5 && openssl md5 knox

.zip.md5 && openssl md5 knox-

h1. Tag Release Candidate

h1. Stage

Follow the instructions output by the sign step above.  Basically execute this command.

h1. Community reviews the RC

https://dist.apache.org/repos/dist/dev/incubator/knox/

h1. Vote

Send a \[VOTE\] email to the dev@knox list.  A template was output by the sign step above as {{target/vote.eml}}.

A candidate for the Apache Knox (Incubator)

/

The release candidate is a zip archive of the sources in:

https://git-wip-us.apache.org/repos/asf/incubator-knox.git
Branch

.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Apache Knox (Incubator) PMC votes are cast.

[ ] +1 Release this package as Apache Knox (Incubator)

h2. Iterate based on feedback until vote passes

h2. Once vote passes, tag the release:

-release --message "Release of v

"
git push origin --tags

h2. Promote

ant promote-release

Verify that the results are accessible.

https://dist.apache.org/repos/dist/release/incubator/knox/

Wait 24 hours for release to propagate to mirrors.

Update site

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

Create version in JIRA for release X.Y.

Send announcements to the user and developer lists.

Update CHANGES with header for new changes

Trademarks

Apache Knox Gateway, Apache, the Apache feather logo and the Apache Knox Gateway project logos are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners.

License

Apache Knox uses the standard Apache license.

Privacy Policy

Apache Knox uses the standard Apache privacy policy.