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