The majority of changes in branch-1 that I see are bug fixes. Only committer attention and bandwidth prevents application to all places. A few are new features or bug fixes that break APIs or change behavior in a manner unsuitable for a patch release. Spotting those isn't hard. Finally, it's true as change application rate increases so does entropy, so occasional test failures or reverts due to issues found during a RC are inevitable. I don't think any rules or process can be superior to committer case by case best judgement. Likewise, PMC attention to the changes incorporated in a release candidate.
> On Feb 11, 2016, at 12:42 PM, Josh Elser <[email protected]> wrote: > > Stack wrote: >>> ... >>> > Let's change our relationship slightly, dev community. If you're working >>> > on >>> > a fix, please also post a patch for branch-1.1. >> >> >> It is a bit tough. That'd be a patch for four branches (at least), three of >> which have diverged in key areas (master, branch-1 and branch-1.2, and >> branch-1.1). Each patch takes a bit of time, especially if some fixup >> needed, and then, if doing the application, there is watching the build >> subsequently to see if my application broke the build (which a seemingly >> innocuous application does with some regularity). A critical fix should be >> done in all branches, but for less-than-critical, I'd be for encouraging >> folks to (rolling) upgrade to get new performance/feature? > > It's a slippery slope trying to decide what has merits to get backported as > well. After meeting compatibility guarantees, how do you decide if some > change if critical enough to be considered for the non-EOL'ed 1.x branches? > > Given that there's only now a 1.2.0 release in the works, it's also kind of > crappy to try to restrict what can go out on a 1.1. I'm all for release > early/often, but that needs to be measured against the cycles to make those > new major/minor releases (so that we can subsequently encourage the community > to adopt those new releases).
