metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Sirota <>
Subject Re: [VOTE] Release Process Documentation
Date Mon, 23 Jan 2017 17:38:17 GMT
Sorry that's a typo. Was meant to be 10.  Just fixed

20.01.2017, 13:22, "" <>:
> -1 (non-binding).
> There appears to be a minor oversight where it goes from Step 9 to Step 14.
> Jon
> On Fri, Jan 20, 2017 at 11:56 AM James Sirota <> wrote:
>>  The document is available here:
>>  and is also pasted in this email for your convenience
>>  Please vote +1, -1, or 0 for neutral. The vote will be open for 72 hours
>>  Metron Release Types
>>  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
>>  Initiating a New Metron Release
>>  Create the MR branch for the previous Metron release by incrementing the
>>  *third* digit of the previous release like so 0.[FR].[*MR++*]. All patches
>>  to the previous Metron release will be checked in under the MR branch and
>>  where it makes sense also under the FR branch. All new features will be
>>  checked in under the FR branch.
>>  Creating a Feature Release
>>  Step 1 - Initiate a discuss thread
>>  Prior to the release The Release manager should do the following
>>  (preferably a month before the release):
>>  Make sure that the list of JIRAs slated for the release accurately
>>  reflects to reflects the pull requests that are currently in master
>>  Construct an email to the Metron dev board (
>> which discusses with the community the
>>  desire to do a release. This email should contain the following:
>>  The list of JIRAs slated for the release with descriptions (use the output
>>  of git log and remove all the JIRAs from the last release’s changelog)
>>  A solicitation of JIRAs that should be included with the next release.
>>  Users should rate them as must/need/good to have as well as volunteering.
>>  A release email template is provided here.
>>  Step 2 - Monitor and Verify JIRAs
>>  Once the community votes for additional JIRAs they want included in the
>>  release verify that the pull requests are in before the release, close
>>  these JIRAs and tag them with the release name. All pull requests and JIRAs
>>  that were not slated for this release will go into the next releases. The
>>  release manager should continue to monitor the JIRA to ensure that the
>>  timetable is on track until the release date. On the release date the
>>  release manager should message the Metron dev board (
>> announcing the code freeze for the
>>  release.
>>  Step 3 - Create the Release Branch and Increment Metron version
>>  Create an branch for the release (from a repo cloned from
>> (assuming
>>  the release is 0.[FR++].0 and working from master):
>>  git checkout -b Metron_0.[FR++].0
>>  git push --set-upstream origin Metron_0.[FR++].0
>>  File a JIRA to increment the Metron version to 0.[FR++].0. Either do it
>>  yourself or have a community member increment the build version for you.
>>  You can look at a pull request for a previous build to see how this is
>>  done. METRON-533 - Up the version for release DONE
>>  Also, the release manager should have a couple of things set up:
>>  A SVN clone of the repo at
>>, We will refer to
>>  this as the dev repo. It will hold the release candidate artifacts
>>  A SVN clone of the repo at
>>, We will
>>  refer to this as the release repo. It will hold the release artifacts.
>>  Step 4 - Create the Release Candidate
>>  Now, for each release candidate, we will tag from that branch. Assuming
>>  that this is RC1:
>>  git checkout Metron_0.[FR++].0 && git pull
>>  git tag apache-metron-0.[FR++].0-rc1-incubating
>>  git push origin —tags
>>  Now we must create the release candidate tarball. From the apache repo,
>>  you should run:
>>   git archive --prefix=apache-metron-0.[FR++].0-rc1-incubating/
>>   apache-metron-0.[FR++].0-rc1-incubating | gzip >
>>   apache-metron-0.[FR++].0-rc-incubating.tar.gz
>>  We will refer to this as the release candidate tarball. *Note: Per Apache
>>  policy, the hardware used to create the candidate tarball must be owned by
>>  the release manager.
>>  The artifacts for a release (or a release candidate, for that matter) are
>>  as follows:
>>  Release (candidate) Tarball
>>   MD5 hash of the release tarball. We will refer to this as the release
>>  candidate tarball.-rc1-incubating.tar.gz >
>>  apache-metron-0.[FR++].0-rc1-incubating.tar.gz.md5)
>>   SHA1 hash of the release tarball (gpg --print-md SHA1
>>  apache-metron-0.[FR++].0-rc1-incubating.tar.gz >
>>  apache-metron-0.[FR++].0-rc1-incubating.tar.gz.sha)
>>  GPG signature of release tarball by the release manager
>>   Assuming your public code signing key is 0xDEADBEEF, so signing for me
>>  would be: gpg -u 0xDEADBEEF --armor --output
>>  apache-metron-0.[FR++].0-rc1-incubating.tar.gz.asc --detach-sig
>>  apache-metron-0.[FR++].0-rc1-incubating.tar.gz
>>  If you do not know your code signing key as release manager, you must
>>  follow the instructions at
>>  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 4 bytes from the key fingerprint.
>>  The LICENSE file from the release tarball
>>  The KEYS file from the release tarball
>>  The DISCLAIMER file from the release tarball
>>  A CHANGES file denoting the changes
>>  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}-incubating (in our case,
>>  it’s 0.[FR++].0-RC1-incubating) in the dev repo. Place the artifacts from
>>  above into this directory, add the directory and commit via the subversion
>>  client:
>>  svn add 0.[FR++].0-RC1-incubating
>>  svn commit -m "Adding artifacts for Metron 0.[FR++].0-RC1 (incubating)”
>>  Step 5 - Verify the build
>>  Go through the build verification checklist to verify that everything
>>  works. These instructions can be found here: Verifying Builds
>>  Step 6 - Verify licensing
>>  Make sure the release complies with the following Apache licensing
>>  guidelines:
>>  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
>>  Step 8 - Call for a incubator release vote
>>  Once the community has successfully voted on a release, we must escalate
>>  the vote to the incubator general. The same VOTE thread original email is
>>  sent to
>>  If issues are found with the release and the vote fails, then the vote
>>  thread is closed with a synopsis of the voting results and a new RC is
>>  worked on in the community
>>  If issues are found with the release and the vote succeeds, then we
>>  proceed to cut the release, but should notify the community of the issues
>>  via an email on the dev list with the accompanying JIRA(s) required to
>>  correct the issue(s).
>>  If no issues are found, then we can cut a release
>>  Again, wait for at least 72 hours and then close the vote.
>>  Step 9 - Stage the finished release
>>  A directory with the name of the version (i.e. 0.3.0) should be made in
>>  the release svn repository
>>  Collateral from the release candidate in the dev repo should be moved to
>>  the above directory and renamed to remove the rc (e.g. mv
>>  apache-metron-0.3.0-rc1-incubating.tar.gz.sha
>>  apache-metron-0.3.0-incubating.tar.gz.sha)
>>  Add the directory and commit via the subversion client:
>>  svn add 0.3.0-RC1-incubating
>>  svn commit -m "Adding artifacts for Metron 0.3.0 (incubating)”
>>  Remove the old releases from the release repo (only the current version
>>  and the KEYS file should exist there).
>>  Step 14 - Announce build
>>  Send an email out to user@ and dev@ to announce the release along with
>>  the changelog and a word of thanks/praise.
>>  Creating a Maintenance Release
>>  Creation of the Maintenance Release should follow exactly the same set of
>>  steps as creating the Feature Release as outlined above, but with two
>>  exception. First, the version incremented on the maintenance release
>>  should be the MR++ so that the release is named 0.[FR].[MR++]. Second, if
>>  a critical JIRA comes in that requires an immediate patch, the votes with
>>  three binding +1's are still required, but Step 1 (discussion) and Step 2
>>  (Jira collecting and tracking), and the 72 hour waiting periods in Steps 7
>>  and 8 can be waived. A critical JIRA is something that is either a
>>  security vulnerability or a functional show stopper.
>>  Now, we must grab the release candidate binary from
>>  Ensuring Consistency between Feature and Maintenance releases
>>  Being able to maintain the previous release train, with only critical or
>>  important bug fixes and security fixes (generally not new features) for
>>  users who are averse to frequent large changes is very important for
>>  production use. They get stability, while the feature code proceeds as
>>  fast as the community wishes. It is important to assure that all commits
>>  to the maintenance release also get made in the feature branch (if
>>  relevant), to avoid the appearance of regressions in the maintenance
>>  branch. The formal process for assuring this is as follows:
>>  Every maintenance release JIRA should have a corresponding feature JIRA to
>>  make sure that the patch is applied consistently to both branches. The
>>  maintenance JIRA should be cloned and appropriate fix version for the
>>  feature release should be applied. If the fix is not relevant to the
>>  feature or maintenance branch then the submitter must explicitly state
>>  this. In general reviewers should refuse a patch PR unless both feature
>>  and maintenance JIRAs have been created.
>>  The release manager has a responsibility to review all commits to the
>>  maintenance line since last release, and make sure they were duplicated to
>>  the feature branch (unless not relevant, which must also be determined).
>>  -------------------
>>  Thank you,
>>  James Sirota
>>  PPMC- Apache Metron (Incubating)
>>  jsirota AT apache DOT org
> --
> Jon
> Sent from my mobile device

Thank you,

James Sirota
PPMC- Apache Metron (Incubating)
jsirota AT apache DOT org

View raw message