[
https://issues.apache.org/jira/browse/METRON-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Foley updated METRON-1020:
-------------------------------
Description:
The following proposed changes are not just editorial in nature, hence will
request vote of the community to change. Regarding the process at
https://cwiki.apache.org/confluence/display/METRON/Release+Process :
* Add a step to tag the final release, as
"apache-metron-<finalversion>-release".
* 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."
* 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:
** 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)
** 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.
was:
The following proposed changes are not just editorial in nature, hence will
request vote of the community to change. Regarding the process at
https://cwiki.apache.org/confluence/display/METRON/Release+Process :
* Add a step to tag the final release, as "apache-metron-<finalversion>-release"
* 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."
* 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:
** 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)
** 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.
> minor changes to release process
> --------------------------------
>
> Key: METRON-1020
> URL: https://issues.apache.org/jira/browse/METRON-1020
> Project: Metron
> Issue Type: Improvement
> Reporter: Matt Foley
>
> The following proposed changes are not just editorial in nature, hence will
> request vote of the community to change. Regarding the process at
> https://cwiki.apache.org/confluence/display/METRON/Release+Process :
> * Add a step to tag the final release, as
> "apache-metron-<finalversion>-release".
> * 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."
> * 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:
> ** 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)
> ** 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.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
