+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 >