I agree with your general logic and understanding of semver. That is why if we are going to violate the strictures of semver, I'd only be happy doing so if support for Java 7 and/or Scala 2.10 were clearly understood to be deprecated already in the 2.0.0 release -- i.e. from the outset not to be understood to be part of the semver guarantees implied in 2.x.
On Wed, Apr 6, 2016 at 11:04 AM, Sean Owen <so...@cloudera.com> wrote: > 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 > >
