In general, I agree - it is preferable to break backward compatibility (where unavoidable) only at major versions. Unfortunately, this usually is planned better - with earlier versions announcing intent of the change - deprecation across multiple releases, defaults changed, etc.
>From the thread, since scala 2.10 was default till last release, it has been mentioned as a large disruption to drop support in 2.0. The same applies for jdk 7 too unfortunately - since backward compatibility is stronger guarantee in jvm compared to scala, it might work better there ? Regards, Mridul 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
