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.


---

Reply via email to