metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lyle <dlyle65...@gmail.com>
Subject Re: [VOTE][PROPOSAL] minor changes to release process
Date Wed, 05 Jul 2017 22:59:17 GMT
+1 on all. Sensible and much welcome changes.

Thanks,

-D...


On Wed, Jul 5, 2017 at 5:47 PM, Matt Foley <mattf@apache.org> 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-<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
>
>
>

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