+1 (binding)

On Tue, Jan 17, 2017 at 11:17 PM, James Sirota <jsir...@apache.org> 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 from the github releases page (
> https://github.com/apache/incubator-metron/releases).  In our case, for
> RC1, that would be https://github.com/apache/incubator-metron/archive/
> apache-metron-0.[FR++].0-rc1-incubating.tar.gz  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 compiles 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] threat 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 gene...@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 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.  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
>

Reply via email to