...
- Make sure all unit and integration tests are passing.
- All tests must pass... if they do not then they need to be fixed before further progress can be made. Each flagon subproject you are attempting to release should contain a README with details on how to run the tests. If it does not, submit a pull request before progressing.
- Update the CHANGELOG.md to reflect the current release, this may also be required for other essential files such as NOTICE, README etc. Ensure all of these files are accurate and up-to-date. It is also advised to include the JIRA release report in CHANGESCHANGELOG.md. This makes it very easy for people to see the relevant changes for this release bundle.
- Now change the version numbers in this branch in package.json.
If you have never made a flagon UserALE.js release, you are required to append your gpg key to the flagon KEYS file. This will then be used to sign all release artifacts. Much more about this can be found here http://apache.org/dev/release-signing.html
Note This is an extremely important part of the release procedure. It is essential to get it right and that all subsequent release managers' KEYS are associated with this file.
- If any changes based on the above have been made, then commit them to the VERSION branch.
...
- In your local copy of flagon (master), navigate to $flagon/target directory and copy the src.zip and src-tar.gz artifacts along with relevant signatures to the above release staging directory.
- You should aim to include all relevant signatures along with these src artifacts. This would entail
SHA and ASC signatures for each artifact. More information on this can be found here - http://apache.org/dev/release-signing.html - copy the CHANGESCHANGELOG.md to this directory as well
- finally, svn add all of the above artifacts and commit them to the flagon dev release staging area
...