I'm fine with keeping old branches around and stating in our docs/READMEs that the branches are unsupported. After looking at a few other open source projects, it seems that this practice is not uncommon.
On Mon, Jan 14, 2019 at 11:42 AM Vinod Kone <[email protected]> wrote: > Hi folks, > > As discussed in the Community WG meeting today, I wanted to send out a > proposal for updating the current support and release policy > <http://mesos.apache.org/documentation/latest/versioning/>. > > Context: According to our release policy, the latest released version and > last 2 released versions are supported at any given time. With an expected > timeline of a minor release every 3 months, that means a minor release is > typically supported for 9 months. So far, we've indicated that a release is > unsupported by deleting the corresponding release branch in our repository. > > The new proposal is as follows: > > - Keep the unsupported release branches and not delete them. Instead, we > would make it clear in the CHANGELOG and also on the downloads > <http://mesos.apache.org/downloads/> page in our website which releases > are supported and which are not. > - If a committer would like to backport a fix to an unsupported release > branch, they can do so. Such a backport is not required but a committer > can > do it if they wish. Contributor and committer should've a dialog > regarding > this. > - CI will keep running against both supported and unsupported release > branches (as it is today) and any issues that might arise will be > fixed on > a best effort basis. > - A committer can ask a contributor to submit a backport review incase > the backport is complicated. Our review tooling (post-reviews and > reviewbot) will be updated to make this possible. > > Based on our experience with the current policy in the last couple of years > and the reality of how some of the organizations are using Mesos, we > believe this tweaks will make it more practical and useful. > > Please let us know your thoughts by replying here or chatting in #community > in our slack channel. > > Thanks, > Vinod (on behalf of Community WG) >
