Re: [VOTE] Release Process Documentation

[Justin Leet]

Another minor correction: the link at "*Note: Per Apache policy
,
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  wrote:

> Sorry that's a typo. Was meant to be 10.  Just fixed
>
> 20.01.2017, 13:22, "zeo...@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 
> 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:
> >>  

Re: [VOTE] Release Process Documentation

[James Sirota]

Sorry that's a typo. Was meant to be 10.  Just fixed

20.01.2017, 13:22, "zeo...@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  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
>>   

Re: [VOTE] Release Process Documentation

[zeo...@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  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 >

Re: [VOTE] Release Process

[James Sirota]

+1 (binding) 

18.01.2017, 13:03, "Matt Foley" :
> +1 (non-binding)
>
> BTW, here is a collection of small editorial changes. Since these are 
> editorial rather than substantive, most project teams accept that they can be 
> made by a responsible PMC member (such as our esteemed chair :-) without 
> re-voting or disrupting a vote in progress. I suggest we let James make these 
> changes without changing the vote, altho of course if anyone who already 
> voted +1 feels that correcting these issues would invalidate your vote, 
> please say so.
>
> Step 4: 2nd bullet: Remove or change obsolete references to the github 
> release tarball.
>
> Step 6: “compiles” --> “complies”
>
> Step 7: “threat” --> “thread”
>
> Introduction, section “Initiating a New Metron Release”
> This sentence is almost certainly a cut-and-paste error:
> “Create the MR branch for the previous Metron release by incrementing 
> the second digit of the previous release like so 0.[FR].[MR].”
> I’m not entirely sure what it should read, but the most probable correction 
> based on the sentence before it would, I think, be (remove the asterisks):
> “Create the MR branch for the previous Metron release by incrementing 
> the *third* digit of the previous release like so 0.[FR].[*MR++*].”
>
> At the end, section “Creating a Maintenance Release”
> We got clarification on the urgent voting issue from Mentors, but steps 2-5 
> aren’t the steps that get waived. The two sentences:
> “Second, if a critical JIRA comes in that requires an immediate patch 
> we may forego steps 2-5 and immediately cut the MR release. By this we mean 
> that 3 binding +1 votes are still required, but the 72 hour waiting period 
> can be waved.”
> Should be changed to:
> “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.”
>
> Cheers,
> --Matt
>
> On 1/17/17, 8:17 PM, "James Sirota"  wrote:
>
> I made the revisions based on the discuss thread
>
> The document is available here:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=66854770
>
> And is also attached for reference to this email.
>
> Please vote +1, -1, or 0 for neutral. The vote will last 72 hours.
>
> Thanks,
> James
>
> -
> 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
> Immediately upon the release of the previous Metron release create two 
> branches: FR ++ and MR. Create the FR++ branch by incrementing the second 
> digit like so 0.[FR++].0. Create the MR branch for the previous Metron 
> release by incrementing the second 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 

Re: [VOTE] Release Process

[Matt Foley]

+1 (non-binding)

BTW, here is a collection of small editorial changes.  Since these are 
editorial rather than substantive, most project teams accept that they can be 
made by a responsible PMC member (such as our esteemed chair :-) without 
re-voting or disrupting a vote in progress.  I suggest we let James make these 
changes without changing the vote, altho of course if anyone who already voted 
+1 feels that correcting these issues would invalidate your vote, please say so.

Step 4: 2nd bullet: Remove or change obsolete references to the github release 
tarball.

Step 6:  “compiles” --> “complies”

Step 7:  “threat” --> “thread”

Introduction, section “Initiating a New Metron Release”
This sentence is almost certainly a cut-and-paste error:
“Create the MR branch for the previous Metron release by incrementing 
the second digit of the previous release like so 0.[FR].[MR].”
I’m not entirely sure what it should read, but the most probable correction 
based on the sentence before it would, I think, be (remove the asterisks):
“Create the MR branch for the previous Metron release by incrementing 
the *third* digit of the previous release like so 0.[FR].[*MR++*].”

At the end, section “Creating a Maintenance Release”
We got clarification on the urgent voting issue from Mentors, but steps 2-5 
aren’t the steps that get waived.  The two sentences:
“Second, if a critical JIRA comes in that requires an immediate patch 
we may forego steps 2-5 and immediately cut the MR release.  By this we mean 
that 3 binding +1 votes are still required, but the 72 hour waiting period can 
be waved.”
Should be changed to:
“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.”

Cheers,
--Matt

On 1/17/17, 8:17 PM, "James Sirota"  wrote:

I made the revisions based on the discuss thread

The document is available here:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=66854770

And is also attached for reference to this email. 

Please vote +1, -1, or 0 for neutral.  The vote will last 72 hours. 

Thanks,
James 

-
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
Immediately upon the release of the previous Metron release create two 
branches: FR ++ and MR.  Create the FR++ branch by incrementing the second 
digit like so 0.[FR++].0.  Create the MR branch for the previous Metron release 
by incrementing the second 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. 
  

Re: [VOTE] Release Process

[Kyle Richardson]

+1 (binding)

-Kyle

On Tue, Jan 17, 2017 at 11:17 PM, James Sirota  wrote:

> I made the revisions based on the discuss thread
>
> The document is available here:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=66854770
>
> And is also attached for reference to this email.
>
> Please vote +1, -1, or 0 for neutral.  The vote will last 72 hours.
>
> Thanks,
> James
>
> -
> 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
> Immediately upon the release of the previous Metron release create two
> branches: FR ++ and MR.  Create the FR++ branch by incrementing the second
> digit like so 0.[FR++].0.  Create the MR branch for the previous Metron
> release by incrementing the second 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 (md5 apache-metron-Now, we must grab the
> release candidate 

Re: [VOTE] Release Process

[Casey Stella]

+1 (binding)

On Tue, Jan 17, 2017 at 11:17 PM, James Sirota  wrote:

> I made the revisions based on the discuss thread
>
> The document is available here:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=66854770
>
> And is also attached for reference to this email.
>
> Please vote +1, -1, or 0 for neutral.  The vote will last 72 hours.
>
> Thanks,
> James
>
> -
> 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
> Immediately upon the release of the previous Metron release create two
> branches: FR ++ and MR.  Create the FR++ branch by incrementing the second
> digit like so 0.[FR++].0.  Create the MR branch for the previous Metron
> release by incrementing the second 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 (md5 apache-metron-Now, we must grab the
> release candidate binary