...

We have two directories here:

• https://dist.apache.org/repos/dist/release/incubator/flagon - This is where PMC approved releases go. DO NOT UPLOAD here until we have a vote passed on dev@flagon... . Check out this folder and name it apache-dist-release-flagon.

• https://dist.apache.org/repos/dist/dev/incubator/flagon - this is where releases to be voted on go. Make the release artifact, post it here, and then post to the [VOTE] thread internally with the flagon community and over the general @incubator community. Check out this folder and name it apache-dist-dev-flagon.

...

• 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.

...

The release utility scripts reside within the release subdirectory.

The release script scripts will:

1. Prepare a staging directory for the source code release
2. Create .tar.gz and .zip artifacts of the source code
3. Invoke npm to build the source code (including running unit tests), and deploy artifacts to a NPM remote repository
4. Save the .tar.gz and .zip artifacts produced by the build of incubator-flagon/release/make-release-artifacts.sh
5. For each of the produced files, produce SHA512 and GnuPG signatures

...

The script takes a -n parameter to work in dry run mode; in this mode, the script will NOT upload NPM artifacts or commit the release to the Subversion repository. This speeds up the process (the NPM deploy in particular slows down the build) and will catch any problems such as PGP or mocha problems much sooner.ONLY create a local copy of release artifacts in the /release folder. It will NOT stage release artifacts to be checked into the staging area. 

# A dry run to 

# A dry run to test everything is OK
$ ./incubator-flagon/release/make-release-artifacts.sh -r $RC_NUMBER -n

# The real build, which will publish artifacts
$ ./incubator-flagon/release/make-release-artifacts.sh -r $RC_NUMBER

Once this has completed,

...

you will need to check-in the release artifacts into the staging environement.

Push the source release artifacts and signatures to dist

...

.apache.org

...

 as described below.

Check out

Push the source release artifacts and signatures to dist.apache.org as described below.

Check out flagon release staging area. The artifacts we push to this area are the ones we make available on official

...

• 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

Next, progress to the creation of the VOTE thread as below....

Verify the release artifacts

TBD

Verify the release artifacts

At minimum you should do a few things to test code that will be available at release:

1. Check the signatures generated by release artifacts: GPG and GPG Keychain provide tools to test .asc signatures and verify that your signing key matches your private key.
2. Check the src builds: Create copies of src.tar and/or src.zip files, and initiate the NPM build and test scripts. Make sure they pass.
3. Check the bin artifacts: Use the UserALE.js example server and point our index.html test page at the minified UserALE.js scripts to ensure that you're generating logs.

Publish to the staging area

Make a signed tag for this release candidate:

$ git tag -a $(VERSION NUMBER) -s -m "Tag release ${VERSION_NAME} release candidate  	${RC_NUMBER}" rel/apache-flagon-useralejs-incubating-${VERSION_NAME}-rc${RC_NUMBER}

$ git show tag $(VERSION NUMBER)

$ git push userale-js $VERSION_NAME && git push apache-git rel/apache-flagon-userale-js-${VERSION_NAME}-rc${RC_NUMBER}origin $(VERSION NUMBER)

$ mkdir apache-flagon-useralejs-incubating-${VERSION_NAME}-rc${RC_NUMBER}

$ svn add apache-flagon-useralejs-incubating-${VERSION_NAME}-rc${RC_NUMBER}
$ svn add CHANGELOG.md
$ svn commit --username $SVN_USERNAME --no-auth-cache --message "Add apache-flagon-useralejs-incubating-${VERSION_NAME}-rc${RC_NUMBER} to dist/dev/flagon"

Prepare the VOTE thread based on the artifacts

...

IT IS ABSOLUTELY ESSENTIAL THAT YOU KEEP THE LOCAL RELEASE COPY !!!!

...

Send out the RESULT thread

...