Answering for myself: I assume everyone is following http://semver.org/ semantic versioning. If not, would be good to hear an alternative theory.
For semver, strictly speaking, minor releases should be backwards-compatible for callers. Are things like stopping support for Java 8 or Scala 2.10 backwards-incompatible? In the end, yes, non-trivially, on both counts. This is why it seems like these changes must go with 2.0 or wait until 3.0. Rules are made to be broken and few software projects do this right. I hear the legitimate concern that getting the latest features and fixes into users hands is really important, and it is. Really, that argues that it's important to keep maintaining the 1.x branch with features and fixes. However, it seems obvious there will never be a 1.7, and probably not 1.6.2, for lack of bandwidth. And indeed it's way too much work given the scope of this project compared to hands to do the work. But this is what's forcing conflation of backwards-compatibility concerns onto a version boundary that doesn't inherently have one. It's a reason I personally root for breaking as many promises and encumbrances that make sense to break all at once at this boundary. Anyway, hope that explains my general logic. On Wed, Apr 6, 2016 at 2:54 AM, Kostas Sakellis <kos...@cloudera.com> wrote: > From both this and the JDK thread, I've noticed (including myself) that > people have different notions of compatibility guarantees between major and > minor versions. > A simple question I have is: What compatibility can we break between minor > vs. major releases? > > It might be worth getting on the same page wrt compatibility guarantees. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
