Re: [VOTE][PROPOSAL] minor changes to release process
Hi, the below changes have been implemented. I also wrote a new page, how to “Change the Build Version Number” (since that’s not so simple to do), and I moved “Website PR Merge” under “Release Process” in the wiki page hierarchy. Please review. If anyone feels I overstepped with editorial changes, please bring it up and we’ll correct. Thanks, --Matt On 7/5/17, 2:47 PM, "Matt Foley" wrote: (The below proposal is also stated in https://issues.apache.org/jira/browse/METRON-1020 ) The following proposed changes are small, but not just editorial in nature, hence will require vote of the community to change. Our bylaws don’t have an action type of Modifying Policy, but it’s probably fair to consider policies to be “included by reference” in Bylaws, so let’s vote on this like a Bylaws change. “Lazy majority of PMC members” applies – same as a release. Regarding the process at https://cwiki.apache.org/confluence/display/METRON/Release+Process : 1. Add a step to tag the final release, as "apache-metron--release". 2. The current policy says that when a critical release is urgently needed, "the 72 hour waiting periods in Steps 7 and 8 can be waived." The formerly referenced Step 8 was for the Incubator vote, so that can be removed as an editorial issue, but we should also allow for not waiting for mirror propagation – let the mirrors catch up as fast as they can. So the text should now read: "the 72 hour waiting period in Step 7 and the wait for mirror propagation in Step 10 can be waived." 3. Finally, it is good practice to increment the build version in POMs immediately AFTER a release, so that builds with new stuff cannot be mistaken for builds of the release version. The current policy says to increment it just BEFORE a release. I suggest changing this to say: a) immediately after a release, increment the MINOR version number (eg, with the 0.4.0 just released, set the new version number to 0.4.1) b) immediately before a release, decide whether it will be a minor or major release. If minor, assure that the minor version number was already incremented after the last release and continue to use that number. If major, change the version number to the desired new major version. c) These version number changes are in master branch. Creation of new branches does not occur until the idea of creating a maintenance branch or a new release branch has been consented by the community. Please share your thoughts and/or vote. Thanks, --Matt
Re: [VOTE][PROPOSAL] minor changes to release process
Vote passes with +1 : 4 votes (3 binding, 1 non-binding) 0 : none -1 : none I’ll edit the doc to reflect the change. Thanks, --Matt On 7/6/17, 10:53 AM, "Matt Foley" wrote: Thanks, all. That’s 3 binding +1’s, so I’m going to proceed with METRON-1021. Vote needs to stay open 72 hours tho, so if anyone else wishes to vote pro or con, you’ll be listened to. Thanks, --Matt On 7/6/17, 10:24 AM, "Nick Allen" wrote: +1 I think that makes a lot of sense. On Wed, Jul 5, 2017 at 5:47 PM, Matt Foley wrote: > (The below proposal is also stated in https://issues.apache.org/ > jira/browse/METRON-1020 ) > > The following proposed changes are small, but not just editorial in > nature, hence will require vote of the community to change. Our bylaws > don’t have an action type of Modifying Policy, but it’s probably fair to > consider policies to be “included by reference” in Bylaws, so let’s vote on > this like a Bylaws change. “Lazy majority of PMC members” applies – same > as a release. > > Regarding the process at https://cwiki.apache.org/ > confluence/display/METRON/Release+Process : > > 1. Add a step to tag the final release, as "apache-metron-- > release". > > 2. The current policy says that when a critical release is urgently > needed, "the 72 hour waiting periods in Steps 7 and 8 can be waived." The > formerly referenced Step 8 was for the Incubator vote, so that can be > removed as an editorial issue, but we should also allow for not waiting for > mirror propagation – let the mirrors catch up as fast as they can. So the > text should now read: "the 72 hour waiting period in Step 7 and the wait > for mirror propagation in Step 10 can be waived." > > 3. Finally, it is good practice to increment the build version in POMs > immediately AFTER a release, so that builds with new stuff cannot be > mistaken for builds of the release version. The current policy says to > increment it just BEFORE a release. I suggest changing this to say: > a) immediately after a release, increment the MINOR version number (eg, > with the 0.4.0 just released, set the new version number to 0.4.1) > b) immediately before a release, decide whether it will be a minor or > major release. If minor, assure that the minor version number was already > incremented after the last release and continue to use that number. If > major, change the version number to the desired new major version. > c) These version number changes are in master branch. Creation of new > branches does not occur until the idea of creating a maintenance branch or > a new release branch has been consented by the community. > > Please share your thoughts and/or vote. > Thanks, > --Matt > > >
Re: [VOTE][PROPOSAL] minor changes to release process
Thanks, all. That’s 3 binding +1’s, so I’m going to proceed with METRON-1021. Vote needs to stay open 72 hours tho, so if anyone else wishes to vote pro or con, you’ll be listened to. Thanks, --Matt On 7/6/17, 10:24 AM, "Nick Allen" wrote: +1 I think that makes a lot of sense. On Wed, Jul 5, 2017 at 5:47 PM, Matt Foley wrote: > (The below proposal is also stated in https://issues.apache.org/ > jira/browse/METRON-1020 ) > > The following proposed changes are small, but not just editorial in > nature, hence will require vote of the community to change. Our bylaws > don’t have an action type of Modifying Policy, but it’s probably fair to > consider policies to be “included by reference” in Bylaws, so let’s vote on > this like a Bylaws change. “Lazy majority of PMC members” applies – same > as a release. > > Regarding the process at https://cwiki.apache.org/ > confluence/display/METRON/Release+Process : > > 1. Add a step to tag the final release, as "apache-metron-- > release". > > 2. The current policy says that when a critical release is urgently > needed, "the 72 hour waiting periods in Steps 7 and 8 can be waived." The > formerly referenced Step 8 was for the Incubator vote, so that can be > removed as an editorial issue, but we should also allow for not waiting for > mirror propagation – let the mirrors catch up as fast as they can. So the > text should now read: "the 72 hour waiting period in Step 7 and the wait > for mirror propagation in Step 10 can be waived." > > 3. Finally, it is good practice to increment the build version in POMs > immediately AFTER a release, so that builds with new stuff cannot be > mistaken for builds of the release version. The current policy says to > increment it just BEFORE a release. I suggest changing this to say: > a) immediately after a release, increment the MINOR version number (eg, > with the 0.4.0 just released, set the new version number to 0.4.1) > b) immediately before a release, decide whether it will be a minor or > major release. If minor, assure that the minor version number was already > incremented after the last release and continue to use that number. If > major, change the version number to the desired new major version. > c) These version number changes are in master branch. Creation of new > branches does not occur until the idea of creating a maintenance branch or > a new release branch has been consented by the community. > > Please share your thoughts and/or vote. > Thanks, > --Matt > > >
Re: [VOTE][PROPOSAL] minor changes to release process
+1 I think that makes a lot of sense. On Wed, Jul 5, 2017 at 5:47 PM, Matt Foley wrote: > (The below proposal is also stated in https://issues.apache.org/ > jira/browse/METRON-1020 ) > > The following proposed changes are small, but not just editorial in > nature, hence will require vote of the community to change. Our bylaws > don’t have an action type of Modifying Policy, but it’s probably fair to > consider policies to be “included by reference” in Bylaws, so let’s vote on > this like a Bylaws change. “Lazy majority of PMC members” applies – same > as a release. > > Regarding the process at https://cwiki.apache.org/ > confluence/display/METRON/Release+Process : > > 1. Add a step to tag the final release, as "apache-metron-- > release". > > 2. The current policy says that when a critical release is urgently > needed, "the 72 hour waiting periods in Steps 7 and 8 can be waived." The > formerly referenced Step 8 was for the Incubator vote, so that can be > removed as an editorial issue, but we should also allow for not waiting for > mirror propagation – let the mirrors catch up as fast as they can. So the > text should now read: "the 72 hour waiting period in Step 7 and the wait > for mirror propagation in Step 10 can be waived." > > 3. Finally, it is good practice to increment the build version in POMs > immediately AFTER a release, so that builds with new stuff cannot be > mistaken for builds of the release version. The current policy says to > increment it just BEFORE a release. I suggest changing this to say: > a) immediately after a release, increment the MINOR version number (eg, > with the 0.4.0 just released, set the new version number to 0.4.1) > b) immediately before a release, decide whether it will be a minor or > major release. If minor, assure that the minor version number was already > incremented after the last release and continue to use that number. If > major, change the version number to the desired new major version. > c) These version number changes are in master branch. Creation of new > branches does not occur until the idea of creating a maintenance branch or > a new release branch has been consented by the community. > > Please share your thoughts and/or vote. > Thanks, > --Matt > > >
Re: [VOTE][PROPOSAL] minor changes to release process
+1 from me as well 05.07.2017, 15:59, "David Lyle" : > +1 on all. Sensible and much welcome changes. > > Thanks, > > -D... > > On Wed, Jul 5, 2017 at 5:47 PM, Matt Foley wrote: > >> (The below proposal is also stated in https://issues.apache.org/ >> jira/browse/METRON-1020 ) >> >> The following proposed changes are small, but not just editorial in >> nature, hence will require vote of the community to change. Our bylaws >> don’t have an action type of Modifying Policy, but it’s probably fair to >> consider policies to be “included by reference” in Bylaws, so let’s vote on >> this like a Bylaws change. “Lazy majority of PMC members” applies – same >> as a release. >> >> Regarding the process at https://cwiki.apache.org/ >> confluence/display/METRON/Release+Process : >> >> 1. Add a step to tag the final release, as "apache-metron-- >> release". >> >> 2. The current policy says that when a critical release is urgently >> needed, "the 72 hour waiting periods in Steps 7 and 8 can be waived." The >> formerly referenced Step 8 was for the Incubator vote, so that can be >> removed as an editorial issue, but we should also allow for not waiting for >> mirror propagation – let the mirrors catch up as fast as they can. So the >> text should now read: "the 72 hour waiting period in Step 7 and the wait >> for mirror propagation in Step 10 can be waived." >> >> 3. Finally, it is good practice to increment the build version in POMs >> immediately AFTER a release, so that builds with new stuff cannot be >> mistaken for builds of the release version. The current policy says to >> increment it just BEFORE a release. I suggest changing this to say: >> a) immediately after a release, increment the MINOR version number (eg, >> with the 0.4.0 just released, set the new version number to 0.4.1) >> b) immediately before a release, decide whether it will be a minor or >> major release. If minor, assure that the minor version number was already >> incremented after the last release and continue to use that number. If >> major, change the version number to the desired new major version. >> c) These version number changes are in master branch. Creation of new >> branches does not occur until the idea of creating a maintenance branch or >> a new release branch has been consented by the community. >> >> Please share your thoughts and/or vote. >> Thanks, >> --Matt --- Thank you, James Sirota PPMC- Apache Metron (Incubating) jsirota AT apache DOT org
Re: [VOTE][PROPOSAL] minor changes to release process
+1 on all. Sensible and much welcome changes. Thanks, -D... On Wed, Jul 5, 2017 at 5:47 PM, Matt Foley wrote: > (The below proposal is also stated in https://issues.apache.org/ > jira/browse/METRON-1020 ) > > The following proposed changes are small, but not just editorial in > nature, hence will require vote of the community to change. Our bylaws > don’t have an action type of Modifying Policy, but it’s probably fair to > consider policies to be “included by reference” in Bylaws, so let’s vote on > this like a Bylaws change. “Lazy majority of PMC members” applies – same > as a release. > > Regarding the process at https://cwiki.apache.org/ > confluence/display/METRON/Release+Process : > > 1. Add a step to tag the final release, as "apache-metron-- > release". > > 2. The current policy says that when a critical release is urgently > needed, "the 72 hour waiting periods in Steps 7 and 8 can be waived." The > formerly referenced Step 8 was for the Incubator vote, so that can be > removed as an editorial issue, but we should also allow for not waiting for > mirror propagation – let the mirrors catch up as fast as they can. So the > text should now read: "the 72 hour waiting period in Step 7 and the wait > for mirror propagation in Step 10 can be waived." > > 3. Finally, it is good practice to increment the build version in POMs > immediately AFTER a release, so that builds with new stuff cannot be > mistaken for builds of the release version. The current policy says to > increment it just BEFORE a release. I suggest changing this to say: > a) immediately after a release, increment the MINOR version number (eg, > with the 0.4.0 just released, set the new version number to 0.4.1) > b) immediately before a release, decide whether it will be a minor or > major release. If minor, assure that the minor version number was already > incremented after the last release and continue to use that number. If > major, change the version number to the desired new major version. > c) These version number changes are in master branch. Creation of new > branches does not occur until the idea of creating a maintenance branch or > a new release branch has been consented by the community. > > Please share your thoughts and/or vote. > Thanks, > --Matt > > >
[VOTE][PROPOSAL] minor changes to release process
(The below proposal is also stated in https://issues.apache.org/jira/browse/METRON-1020 ) The following proposed changes are small, but not just editorial in nature, hence will require vote of the community to change. Our bylaws don’t have an action type of Modifying Policy, but it’s probably fair to consider policies to be “included by reference” in Bylaws, so let’s vote on this like a Bylaws change. “Lazy majority of PMC members” applies – same as a release. Regarding the process at https://cwiki.apache.org/confluence/display/METRON/Release+Process : 1. Add a step to tag the final release, as "apache-metron--release". 2. The current policy says that when a critical release is urgently needed, "the 72 hour waiting periods in Steps 7 and 8 can be waived." The formerly referenced Step 8 was for the Incubator vote, so that can be removed as an editorial issue, but we should also allow for not waiting for mirror propagation – let the mirrors catch up as fast as they can. So the text should now read: "the 72 hour waiting period in Step 7 and the wait for mirror propagation in Step 10 can be waived." 3. Finally, it is good practice to increment the build version in POMs immediately AFTER a release, so that builds with new stuff cannot be mistaken for builds of the release version. The current policy says to increment it just BEFORE a release. I suggest changing this to say: a) immediately after a release, increment the MINOR version number (eg, with the 0.4.0 just released, set the new version number to 0.4.1) b) immediately before a release, decide whether it will be a minor or major release. If minor, assure that the minor version number was already incremented after the last release and continue to use that number. If major, change the version number to the desired new major version. c) These version number changes are in master branch. Creation of new branches does not occur until the idea of creating a maintenance branch or a new release branch has been consented by the community. Please share your thoughts and/or vote. Thanks, --Matt
