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).
