metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Allen <>
Subject Re: [VOTE][PROPOSAL] minor changes to release process
Date Thu, 06 Jul 2017 17:24:53 GMT
+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 on
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message