...
There are two types of Metron releases:
- Feature Release (FR) - this is a release that has a significant step forward in feature capability and is denoted by an upgrade of the second digit
- Maintenance Release (MR) - this is a set of patches and fixes that are issued following the FR and is denoted by an upgrade of the third digit
Release Naming Convention
Metron build naming convention is as follows: 0.[FR].[MR]. We keep the 0. notation to signify that the project is still under active development and we will hold a community vote to go to 1.x at a future time. The first release in a Feature Release line is 0.[FR].0. There may or may not ever be a release 0.[FR].1, depending whether the community decides to create follow-on Maintenance Release(s) or just go straight to the next Feature Release (which would be named 0.[FR+1].0).
...
Once this is done, the release master manager should ensure their public key is provided in the KEYS file, following the usual Pull Request process. See
| Jira | ||||||
|---|---|---|---|---|---|---|
|
Currently, the KEYS file is only pushed with a main Metron release. This means that, when there is a new release manager, they will be unable to release apache/metron-bro-kafka-plugin without a release of apache/metron.
Step 1 - Initiate a [DISCUSS] thread
...
Also, run the JIRA verification tool at build_utilsdev-utilities/release-utils/validate-jira-for-releaserelease, and before the end of the release process assure that its results are made consistent with the release CHANGES document (see below).
...
Determine the current build version number on master branch, as described here. If it is not the desired release number (for instance, if we desire to release version 0.5.0, but the current build version is 0.4.1), then submit a PR to update the build version number as described in Change the Build Version Number, get approval, and commit.
Step 4 -
...
Create a branch for the release (from a git repo cloned from https://git-wip-us.apache.org/repos/asf/metron.git). All the example commands below assume the desired release is 0.[FR].0:
git checkout master
git checkout -b Metron_0.[FR].0
git push --set-upstream origin Metron_0.[FR].0
Also, the release manager should have a couple of things set up:
- A SVN clone of the repo at https://dist.apache.org/repos/dist/dev/metron, We will refer to this as the dev repo. It will hold the release candidate artifacts
- A SVN clone of the repo at https://dist.apache.org/repos/dist/release/metron, We will refer to this as the release repo. It will hold the release artifacts.
Step 4 - Review the Apache Documentation for Releases
Review the Apache documentation around Release Distribution and Release Policy. Make sure to understand what build artifacts are expected to produced, what are not expected to be produced (e.g. MD5 used to be supplied, but is now omitted), what is expected of download links, etc.
https://www.apache.org/dev/release-distribution
https://apache.org/legal/release-policy.html
Step 5 - Create the Release Candidate
Now, for each release candidate, we will tag from that branch. The tag must be created before executing the `git archive` command. However, do NOT push the tag until just before you announce the corresponding RC (step 8 below). Bugs or other issues may come up during verification that make you decide to dump this RC and build a new one, and if you've already pushed the RC tag you'll have to increment the tag number.
Assuming that this is RC1 (the first Release Candidate), create the tag as below. (If you are re-using a tag that has NOT been pushed, you must first delete the previous instance with `git tag -d apache-metron-0.[FR].0-rc1`. If the tag has already been pushed, do not try to re-use it, just increment to the next rc#.)
git checkout Metron_0.[FR].0 && git pull
git tag apache-metron-0.[FR].0-rc1
Now we must create the release candidate tarball from this tag. From the apache repo, you should run:
Review the Apache Documentation for Releases
Review the Apache documentation around Release Distribution and Release Policy. Make sure to understand what build artifacts are expected to produced, what are not expected to be produced (e.g. MD5 and SHA-1 used to be supplied, but are now omitted), what is expected of download links, etc. This may necessitate updates to the release process and/or script to handle.
https://www.apache.org/dev/release-distribution
https://apache.org/legal/release-policy.html
Step 5 - Create the Release Candidate
A script exists at dev-utilities/release-utils/prepare-release-candidate to create a release candidate and the appropriate accompanying artifacts. Follow the instructions at dev-utilities/release-utils/README.md#prepare-release-candidate.
In the following descriptions, [N] is used to denote the release candidate number. This starts at 1 and must be incremented each time a RC is pushed to Git.
It's strongly recommended to do a practice run first, validate the build (Verifying Builds) and licensing (see http://www.apache.org/foundation/license-faq.html), then do a live run. A live run will do the appropriate Git and SVN pushed.
This script will:
- Do an SVN clone of the repo at https://dist.apache.org/repos/dist/dev/metron. We will refer to this as the dev repo. It will hold the release candidate artifacts
- Do an SVN clone of the repo at https://dist.apache.org/repos/dist/release/metron. We will refer to this as the release repo. It will hold the release artifacts.
- Do a Git clone of the repo at https://git-wip-us.apache.org/repos/asf/metron.git. This holds the source code for the release candidate.
- Create appropriate tags (following the naming convention `git tag apache
...
- -metron-0.[FR].
...
- [MR]-rc[N]`).
- Create the release tarball (following the naming convention apache-metron-0.[FR].[MR]-rc[N].tar.gz).
- Create the appropriate release artifacts. The script will create these, and manual instructions are provided here
We will refer to this as the release candidate tarball. Notes:
- Per Apache policy, the hardware used to create the candidate tarball must be owned by the release manager.
- It often takes publishing several Release Candidates to achieve an approved release. Be careful to keep incrementing the "rc#" on all artifacts in each generation, so as to avoid confusion.
...
- :
- Release (candidate) Tarball
...
- Per Apache guidance, we use SHA512 hash digests in the signing process,
...
- see here
...
- for how to set your gpg defaults, and upgrade your signing keys if you have old ones. Likewise, do not use 4-byte fingerprints, like "DEAD BEEF" or "0xDEADBEEF", to refer to your signing key, as these have been demonstrated vulnerable. Instead use 8-byte fingerprints, like "BADD CAFE DEAD BEEF" or "0xBADDCAFEDEADBEEF".
- SHA512 hash of the release tarball; here we will also provide SHA256 hashes for backward compatibility:
- gpg --print-md SHA512 apache-metron-0.[FR].0-rc1.tar.gz > apache-metron-0.[FR].0-rc1.tar.gz.sha512
- gpg --print-md SHA256 apache-metron-0.[FR].0-rc1.tar.gz > apache-metron-0.[FR].0-rc1.tar.gz.sha256
- GPG signature of release tarball by the release manager
- Assuming your 8-byte public code signing key fingerprint is 0xBADDCAFEDEADBEEF, so your signing command would be: gpg -u 0xBADDCAFEDEADBEEF --armor --output apache-metron-0.[FR].0-rc1.tar.gz.asc --detach-sig apache-metron-0.[FR].0-rc1.tar.gz
- Note: You only need the -u arg if you have more than one public/private key pair generated. If you have forgotten it, you can find it from the output of gpg --fingerprint. It’s the last 8 bytes (16 hex characters) from the key fingerprint
...
- .
- If you do not know, or cannot recover, your code signing key and password as release manager, you must start over with a new code signing key. Follow the instructions at https://www.apache.org/dev/release-signing.html#generate . You should then link your new code signing key into Apache's web of trust.
- The LICENSE and NOTICE files from the release tarball
- The KEYS file from the release tarball
- A CHANGES file denoting the changes
- Create the directory in the dev repo for the artifacts (following the convention `0.[FR].[MR]-RC[N]`). A live run will also commit them (`svn
...
- We usually construct this by taking the output of git log | grep METRON | sed 's/\[//g' | sed 's/\]//g' | grep -v "http" and removing the JIRAs from the previous releases (it’s in time sorted order so this is easy).
Create a directory named ${VERSION}-RC${RC_NUM} (in our case, it’s 0.[FR].0-RC1) in the dev repo. Place the artifacts from above into this directory, add the directory and commit via the subversion client:
...
- commit -m "Adding artifacts for Metron 0.[FR]
...
- .[MR]-RC[N]"`). A practice run will simply print the commands.
Step 6 - Push the Git Tag
Step 6 - Verify the build
Go through the build verification checklist to verify that everything works. These instructions can be found here: Verifying Builds
Step 7 - Verify licensing
Make sure the release complies with the following Apache licensing guidelines: http://www.apache.org/foundation/license-faq.html
...
When you're confident this release candidate is worthy to be tested by the community, push the tag to the public git repo. Chdir back to the local repo from which you created the release candidate tarball, and verify that the tag is present:
git tag
Then push the tag to the public repo:
git push origin tag apache-metron-0.[FR].0-rc1[MR]-rc[N]
Browse the public repo and confirm the tag has been pushed successfully.
Step
...
7 - Call for a community release vote
Next initiate a [VOTE] thread on the dev list to announce the build vote. The vote email template can be found here: Build Vote Template. Allow at least 72 hours for the community to vote on the release.
...
When you get enough votes, close the vote by replying [RESULT][VOTE] to the email thread with the tally of all the votes. Again, wait for at least 72 hours before closing the vote.
Step
...
8 - Tag the finished release
apache/metron
After the vote passes, re-tag the RC as the release. In your working repo for the release (cloned from https://git-wip-us.apache.org/repos/asf/metron.git), do:
git tag apache-metron-0.[FR].0[MR]-release apache-metron-0.[FR].0-rc1[MR]-rc[N]
git push origin tag apache-metron-0.[FR].0[MR]-release
apache/metron-bro-plugin-kafka
...
git tag apache-metron-bro-plugin-kafka-0.[FR].0[MR]-release apache-metron-bro-plugin-kafka-0.[FR].0[MR]-rc1
git tag 0.[FR] apache-metron-bro-plugin-kafka-0.[FR].0[MR]-release
git push origin tag apache-metron-0.[FR].0[MR]-release
git push origin tag 0.[FR]
The 0.[FR] tag is created to allow the release to be handled appropriately by bro-pkg.
Step
...
9 - Stage the finished release
A directory with the name of the release version should be made in the release svn repository
...
Confirm that the new release is visible in dist, by pointing your browser at https://dist.apache.org/repos/dist/release/metron/ . It should appear promptly, but may not be instantaneous.
Step
...
10 - Update the Website to point at the new release location
Open a JIRA with title "update public web site to point at 0.4.0 [FR].[MR] new release". Suppose it is METRON-1234. Make a new git clone of Metron, and create a working branch for the website update submission:
cd <workdir>
git clone https://github.com/apache/metron.git
cd metron
git checkout -b METRON-1234 apache-metron-0.[FR].0[MR]-release
Now rebuild the doc and web sites, and copy the built site-book to site/current-book
...
Remember that download links in the Website should never point directly at dist, but rather always point at mirrors via http://www.apache.org/dyn/closer.cgi/metron/[VERSION]/... However, the signature files (.asc and .sha*) must point at https://www.apache.org/dist/metron/0.[FR].[MR]/... .
Step 13 11 - Wait for the new release to propagate to mirrors
According to Apache docs, "It may take up to 24 hours or more for a newly published release to be sync'd to all mirrors. Mirrors have their own schedules. Mirrors are required to check at least once a day, but most will check for updates 2 to 4 times per day." At least wait until a spot-check of mirrors on http://www.apache.org/dyn/closer.cgi/ show the new release.
Step
...
12 - Add the release to the Apache database
Add the release to Apache so it shows up in the board report generator by going here: https://reporter.apache.org/addrelease.html?metron
Step
...
13 - Announce the release
Commit the built Website to the Metron asf-site branch, per the final instructions from Website PR Merge, so it is publicly visible.
Send an email out to user@ and dev@ to announce the release along with the changelog and a word of thanks/praise.
Step
...
14 - Clean up
Remove the old releases from the release repo, after making sure they are already mirrored into the archive repo. Only the current version and the KEYS file should be in the release repo.
...