metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Foley <>
Subject Re: [VOTE][PROPOSAL] minor changes to release process
Date Tue, 11 Jul 2017 01:06:58 GMT
Vote passes with 
+1 : 4 votes (3 binding, 1 non-binding)
0 : none
-1 : none

I’ll edit the doc to reflect the change.

On 7/6/17, 10:53 AM, "Matt Foley" < on behalf of>

    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.
    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
        > 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
        > this like a Bylaws change.  “Lazy majority of PMC members” applies – same
        > as a release.
        > Regarding the process at
        > confluence/display/METRON/Release+Process :
        > 1. Add a step to tag the final release, as "apache-metron-<finalversion>-
        > 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

View raw message