Two other criteria that I use when deciding what to backport: - Is it a regression from a previous minor release? I'm much more likely to backport fixes in this case, as I'd love for most people to stay up to date. - How scary is the change? I think the primary goal is stability of the maintenance branches. When I am confident that something is isolated and unlikely to break things (i.e. I'm fixing a confusing error message), then i'm much more likely to backport it.
Regarding the length of time to continue backporting, I mostly don't backport to N-1, but this is partially because SQL is changing too fast for that to generally be useful. These old branches usually only get attention from me when there is an explicit request. I'd love to hear more feedback from others. Michael On Tue, Mar 24, 2015 at 6:13 AM, Sean Owen <so...@cloudera.com> wrote: > So far, my rule of thumb has been: > > - Don't back-port new features or improvements in general, only bug fixes > - Don't back-port minor bug fixes > - Back-port bug fixes that seem important enough to not wait for the > next minor release > - Back-port site doc changes to the release most likely to go out > next, to make it a part of the next site publish > > But, how far should back-ports go, in general? If the last minor > release was 1.N, then to branch 1.N surely. Farther back is a question > of expectation for support of past minor releases. Given the pace of > change and time available, I assume there's not much support for > continuing to use release 1.(N-1) and very little for 1.(N-2). > > Concretely: does anyone expect a 1.1.2 release ever? a 1.2.2 release? > It'd be good to hear the received wisdom explicitly. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org > For additional commands, e-mail: dev-h...@spark.apache.org > >
