metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Sirota <jsir...@apache.org>
Subject Re: [VOTE][PROPOSAL] minor changes to release process
Date Wed, 05 Jul 2017 23:00:54 GMT
+1 from me as well


05.07.2017, 15:59, "David Lyle" <dlyle65535@gmail.com>:
> +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

------------------- 
Thank you,

James Sirota
PPMC- Apache Metron (Incubating)
jsirota AT apache DOT org

Mime
View raw message