spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mridul Muralidharan <>
Subject Re: Discuss: commit to Scala 2.10 support for Spark 2.x lifecycle
Date Wed, 06 Apr 2016 18:51:44 GMT
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 ?


On Wed, Apr 6, 2016 at 11:04 AM, Sean Owen <> wrote:
> Answering for myself: I assume everyone is following
> 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 <> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message