Jacopo, Your first suggestion is a bit cumbersome. If an issue affects multiple versions and it is not fixed in all versions, why not simply keep it open as long as the release branch it affects is in the maintenance cycle?
Your second suggestion is ambiguous. Which part of the community are you referring to with respect to decreased interest? What if the installed versions amongst our user base is significant different than you expect? We can suggest the users what to use, but it is down to migration costs and added value of the newer version how customers decide. And what if there is enough interest among the non-committing contributors to continue to support a release branch, while none of the committers is willing to? Is the PMC going to invite these non-committing contributors to be committers as well? Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Mon, Sep 22, 2014 at 3:51 PM, Jacopo Cappellato < jacopo.cappell...@hotwaxmedia.com> wrote: > Some ideas to manage this workflow in a better way: > > * if a bug that affects an old release branch is not backported, when we > resolve the ticket we create a new one that is linked to the original and > has the field "affected releases" set the affected old branch; this will be > a placeholder for the ones willing to maintain the old branch > * about the end of life of release branches: when we perceive a decreasing > interest from the community to backport to an old release, we could run a > vote to decide if the community is ok to anticipate the end of life of a > release branch; the ones that vote to keep the branch alive could offer to > help in the backporting process > > Jacopo > > >
