You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@metron.apache.org by James Sirota <js...@apache.org> on 2017/01/20 16:56:25 UTC
[VOTE] Release Process Documentation
The document is available here:
https://cwiki.apache.org/confluence/display/METRON/Release+Process
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 (dev@metron.incubator.apache.org) 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\u2019s 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 (dev@metron.incubator.apache.org) 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 https://git-wip-us.apache.org/repos/asf/incubator-metron.git). (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 https://dist.apache.org/repos/dist/dev/incubator/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/incubator/metron, 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 \u2014tags
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 https://www.apache.org/dev/release-signing.html#generate
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 \u2014fingerprint. It\u2019s 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 \u201chttp\u201d and removing the JIRAs from the previous releases (it\u2019s in time sorted order so this is easy).
Create a directory named ${VERSION}-RC${RC_NUM}-incubating (in our case, it\u2019s 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)\u201d
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: http://www.apache.org/foundation/license-faq.html
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 general@incubator.apache.org
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)\u201d
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
Re: [VOTE] Release Process Documentation
Posted by Justin Leet <ju...@gmail.com>.
Another minor correction: the link at "*Note: Per Apache policy
<https://cwiki.apache.org/confluence/We%20will%20refer%20to%20this%20as%20the%20release%20candidate%20tarball.%20*Note:%20Per%20apache%20policy,%20the%20hardware%20used%20to%20create%20the%20candidate%20tarball%20must%20be%20owned%20by%20the%20release%20manager.>,
the hardware used to create the candidate tarball must be owned by the
release manager." is broken.
Justin
On Mon, Jan 23, 2017 at 12:38 PM, James Sirota <js...@apache.org> wrote:
> Sorry that's a typo. Was meant to be 10. Just fixed
>
> 20.01.2017, 13:22, "Zeolla@GMail.com" <ze...@gmail.com>:
> > -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 <js...@apache.org>
> wrote:
> >
> >> The document is available here:
> >> https://cwiki.apache.org/confluence/display/METRON/Release+Process
> >>
> >> 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 (
> >> dev@metron.incubator.apache.org) 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 (
> >> dev@metron.incubator.apache.org) 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
> >> https://git-wip-us.apache.org/repos/asf/incubator-metron.git).
> (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
> >> https://dist.apache.org/repos/dist/dev/incubator/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/incubator/metron, 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
> >> https://www.apache.org/dev/release-signing.html#generate
> >> 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: http://www.apache.org/foundation/license-faq.html
> >> 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 general@incubator.apache.org
> >>
> >> 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
>
Re: [VOTE] Release Process Documentation
Posted by James Sirota <js...@apache.org>.
Sorry that's a typo. Was meant to be 10. Just fixed
20.01.2017, 13:22, "Zeolla@GMail.com" <ze...@gmail.com>:
> -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 <js...@apache.org> wrote:
>
>> �The document is available here:
>> �https://cwiki.apache.org/confluence/display/METRON/Release+Process
>>
>> �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 (
>> �dev@metron.incubator.apache.org) 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\u2019s 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 (
>> �dev@metron.incubator.apache.org) 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
>> �https://git-wip-us.apache.org/repos/asf/incubator-metron.git). (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
>> �https://dist.apache.org/repos/dist/dev/incubator/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/incubator/metron, 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 \u2014tags
>> �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
>> �https://www.apache.org/dev/release-signing.html#generate
>> �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 \u2014fingerprint. It\u2019s 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 \u201chttp\u201d and removing the JIRAs from
>> �the previous releases (it\u2019s in time sorted order so this is easy).
>>
>> �Create a directory named ${VERSION}-RC${RC_NUM}-incubating (in our case,
>> �it\u2019s 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)\u201d
>> �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: http://www.apache.org/foundation/license-faq.html
>> �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 general@incubator.apache.org
>>
>> �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)\u201d
>>
>> �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
Re: [VOTE] Release Process Documentation
Posted by "Zeolla@GMail.com" <ze...@gmail.com>.
-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 <js...@apache.org> wrote:
> The document is available here:
> https://cwiki.apache.org/confluence/display/METRON/Release+Process
>
> 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 (
> dev@metron.incubator.apache.org) 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 (
> dev@metron.incubator.apache.org) 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
> https://git-wip-us.apache.org/repos/asf/incubator-metron.git). (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
> https://dist.apache.org/repos/dist/dev/incubator/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/incubator/metron, 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
> https://www.apache.org/dev/release-signing.html#generate
> 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: http://www.apache.org/foundation/license-faq.html
> 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 general@incubator.apache.org
>
> 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