My philosophy has been basically what you suggested, Sean. One thing you didn't mention though is if a bug fix seems complicated, I will think very hard before back-porting it. This is because "fixes" can introduce their own new bugs, in some cases worse than the original issue. It's really bad to have some upgrade to a patch release and see a regression - with our current approach this almost never happens.
I will usually try to backport up to N-2, if it can be back-ported reasonably easily (for instance, with minor or no code changes). The reason I do this is that vendors do end up supporting older versions, and it's nice for them if some committer has backported a fix that they can then pull in, even if we never ship it. In terms of doing older maintenance releases, this one I think we should do according to severity of issues (for instance, if there is a security issue) or based on general command from the community. I haven't initiated many 1.X.2 releases recently because I didn't see huge demand. However, personally I don't mind doing these if there is a lot of demand, at least for releases where ".0" has gone out in the last six months. On Tue, Mar 24, 2015 at 11:23 AM, Michael Armbrust <mich...@databricks.com> wrote: > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
