> I > don't think we should force the project into a regular every-N-weeks > cadence without being sure that the release process can keep up.
That sounds good to me. It is my understanding that the way Kudu does it is that someone generally volunteers to drive the next K releases, anticipating creating the release branch every N weeks. > I do. At some point before we start taking breaking changes we should cut a > 2.X sustaining branch so that anyone who wants to make further release off > the 2.X series can do so. SGTM > However, I also think there's a place for individual feature branches, as > long as they are usually merged back to trunk after the branch meets its > requirements. A good example is the PPC work - it's a good idea to get that > stable before it's merged to trunk, but once it's merged, the branch > shouldn't be needed any more. > > Long-lived feature branches are a pain, but we shouldn't rule them out > entirely if some contributors want to undertake speculative work. SGTM. Does anyone else have concerns about this branching model?
