...

This depends on how active the tree is at the time.

svngit cpcheckout  -mb "Creating wave-0.3-release branch" \
            https://svn.apache.org/repos/asf/incubator/wave/trunk \
            https://svn.apache.org/repos/asf/incubator/wave/branches/wave-0.34.0-release

Then check out this branch, to do any release work needed.

...

Ensure that all new source files have the Apache License attached, and any dependencies licenses are correctly noted in NOTICE.

Run the license audit tool and inspect the output:

ant audit-licenses

Check export status of any cryptographic dependencies. (Unknown currently whether we need an ECCN or not) 

Set version number in file

The version number is currently stored in build.properties in the waveinabox.version string.
Whilst the project is still incubating, the word 'incubating' must appear in the version string.

Build the release artefacts

Simply running

 ant release 

should be enough to build, run tests, and package as tar.bz2 and zips in the dist directory.
Manually inspect to ensure the 4 archives were all generated correctly:

1. 'ant dist' works from the unpacked source archives
2. Jar manifests contain LICENSE and NOTICE
3. Jar manifests have the following properties:

Specification-Vendor
Specification-Title
Specification-Version
Implementation-Vendor
Implementation-Title
Implementation-Version

TODO: Do we need Extension-Name, Implementation-Vendor-Id as well?

Make a Release Candidate

Bump version number

Adjust 'waveinabox.version' in build.properties. Do not include RC in the version number here.

Create CHANGES

This could be assembled from either JIRA, or directly from the Subversion logs.
(Currently JIRA is not organized/complete-enough to do this, so subversion logs should be used).
The best way to get a list of all the commits since the previous release is by:

cd {project-base}/tags
svn log --stop-on-copy wave-0.3
#The last reported revision is the revision used for the tag.
#(Theoretically only one listed being a tag directory)
cd ..
svn log -v -rNNNN:HEAD trunk > CHANGES

The version number should be in the form described at: http://semver.org/

Basically:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

For example:  0.4.0-rc.6-incubating

Every release should usually increase the MINOR version and reset the PATCH version.

Create CHANGES

I suggest using the following git log, to produce a one-line-per-change list of all commits.
(An alternative, would be to use the JIRA id's - but not everything goes through Jira (notably most of my stuff doesn't! ))

git log --pretty=medium

Put this the 'Full log' section.
I suggest hand-writing the 'Summary since X' at the start of the fileUsing 'svn diff' may be worthwhile if the time between releases shrinks, or for some emergency (security) release, where there may have only been a few commits between releases.
NOTE: Do not use selecting by date in subversion. As this is not fully reliable in the ASF repository.

Create RELEASE-NOTES

TODO: decide on a format
Refer to the notes used in the previous release for the format of how to write them.
Break at 80 chars as is conventional.
Include:

• Description of the project
• Any major changes (otherwise see CHANGES) Is this really needed given the summary in CHANGES?
• Any compatibility issues (and mention if none)
• Any upgrading procedures needed
• Make another note of the required Java version

Tag the RC

...

Make the RC

There are two ways to create the artefacts. The preferred way is to use the artefacts created by Jenkins.

Download zip with all artefacts from https://

...

builds.apache.org/

...

view/

...

S-Z/

...

view/

...

Wave/

...

job/wave-artifacts/lastSuccessfulBuild/artifact/*zip*/archive.zip

wget 0.3-release \
            https://svnbuilds.apache.org/reposview/asfS-Z/incubatorview/waveWave/tagsjob/wave-0.3-rc1

Make the RC

artifacts/lastSuccessfulBuild/artifact/*zip*/archive.zip
 unzip archive.zip

Or, create the artefacts manually. Make sure to run the unit tests first. Run

 ant release 

.
Check that the produced code still works!

Check that source packages don't include any binaries.

Sign the release using your GPG key, and record SHA512 checksums for the files. (See my script at https://people.apache.org/~al/artefact-sign.sh)

#!/bin/zsh
#Assumes it is being run in the folder with artefacts.

PRE="apache-wave-"
for f in $PRE*; do
gpg --armor --output $f.asc --detach-sig $f
gpg --print-md SHA512 $f > $f.sha
done

You need to append you signature/public key to the KEYS file, look there for instructions.

Upload the Artefacts.

Upload the src+bin tar+zip somewhere so that it can be found.

The release candidate should be uploaded to the "dev" folder first to allow inspection and voting.
Either put in your space at

svn checkout  https://

...

dist.apache.org/repos/dist/dev/incubator/wave/

Create a new folder under ~name/, or make a folder and host in https://dist.apache.org/repos/dist/dev/incubator/wave for the new release candidate and copy there the signed artefacts and then commit.

Vote for release

Send a vote mail for RC

...

Whilst Wave is still an incubating project, send a VOTE email to general@incubator.apache.org to get PMC votes. Handle in the same way as the internal vote.

Publish

...

accepted RC

To publish copy the artefacts into https://dist.apache.org/repos/dist/release/incubator/wave/ from the dist/dev/incubator/wave/ (delete old artefacts if needed, they were automatically archived already) and commit.TODO