Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1188
I could be wrong, but I think we've been fairly loose about it. Matt may
have done some management of it, but it would have been entirely manual. In
most cases we should be able to release from master without concern (after all,
if it can't be released, why is it in master?)
Maintenance releases are definitely something that should be considered
(although I don't think we've ever done one). I believe that if we were doing a
maintenance release, we'd just be keeping a branch up to date and releasing
from that branch.
Per the release process wiki page
> Maintaining a Maintenance Branch
>
>Being able to maintain the previous release train, with only critical or
important bug fixes and security fixes (generally not new features) for users
who are averse to frequent large changes is very important for production use.
They get stability, while the new feature release code line proceeds as fast as
the community wishes.
>
> When needed, and with community discussion, create a Maintenance Branch
for the previous Metron release by incrementing the *third* digit of the
previous release like so 0.[FR].[*MR++*]. All patches to the previous Metron
release will be checked in under the MR branch and where it makes sense also
under the master branch. All new features will be checked in under the master
branch.
Maybe we can address at least the majority of cases for both of these by
adding an option for a commit/branch to use as the basis of the RC? To be more
thorough, we'd probably need to be more flexible on what exactly goes in, but
that seems like a fairly straightforward way to build on what we have.
---
