Gauge interest in and fixes/features wanted for TLS for 2.10.x

[milessabin]

2.12.0 has arrived, but lots of people are still stuck on 2.10.x. In principle it would be possible to backport fixes and features from 2.11.x and 2.12.x to Scala 2.10.x to make it easier to support cross building across all three major versions without unduly limiting people's ability to exploit new features of 2.12.0.

Things we might consider adding are,

• Fix for SI-2712
• Fix for SI-7046
• Literal types
• Right biased Either

Please indicate your general interest here and add additional fixes/features in comments. Nb. things which aren't already supported on both 2.11.x and 2.12.x are unlikely to be considered.

Could people reacting with a 👍 or 👎 please give their reasons pro/con.

Nb. This isn't a question about whether we think other organizations ought to move to 2.11+ (whatever we might think, some don't have an easy choice) ... it's a question about whether we allow ourselves to use newer language features in our own projects while we continue to support users who can't move forward (if that's what we choose to do).

[adelbertc]

Whatever is causing FS2 to not compile on 2.10.x would be awesome. It seems like something in Scala 2.10 is demanding some silly hand-holding, see: typelevel/fs2#755

A lot of the error messages are something like "expected Handle[F, A] found Handle[F[_], A]" Some silly type annotations (shown in the ticket linked above) seem to make the compiler happy.

This may also simplify life for libraries using FS2 like Doobie and HTTP4S. /cc @tpolecat @rossabaker

[milessabin]

@adelbertc are you able to identify the commit that fixed this in 2.11.x? Try a git bisect.

[nafg]

Is right-biased Either source-compatible?

[milessabin]

@nafg it's neither source nor binary compatible. I don't think that's a problem ... the point of this would be to build a bridge between a now unsupported old release and current releases.

[milessabin]

FWIW, a backport of right biased Either to 2.11.x would be highly desirable.

[nafg]

@milessabin I don't get it. Supposing I have a project that I can't upgrade because it uses library X which only exists for 2.10, if library X uses Either and I upgrade to 2.10.N with changed Either, won't I get runtime linking errors inside of X?
(Same for 2.11)

[milessabin]

@nafg the 2.12.x change is binary incompatible, but I'm fairly confident we can come up with something which is binary compatible with 2.10.x and source compatible with 2.12.x.

[milessabin]

Would people reacting with a 👍 or 👎 please give their reasons pro/con.

[rossabaker]

When I was stuck on Scala 2.10, I would have welcomed this. TLS Scala has been an easy and positive transition wherever I've tried. But my organization had cooled to Scala and had zero interest in a using a compiler fork. We were on 2.10 because we were slowly divesting ourselves of Scala. If this is why others are on 2.10, this may excite individual developers but see little adoption.

If people are on 2.10 and committed to Scala in some form, then 👍.

[tpolecat]

This would let me simplify some things in doobie and potentially support some new stuff in 2.10 that I wasn't planning on. But I'm concerned that the long-term effect will be an increased maintenance burden on all of us, since we're removing the main motivation to upgrade. So I don't have strong feelings one way or the other. I do suspect that the main beneficiaries are likely to be large orgs, who might be in a position to pay Lightbend to do this if it's that important.

[fommil]

ensime is only supporting 2.10 until sbt 1.0 comes out, which will probably coincide with ensime 3.0 (sometime in 2017). We're not currently using any TLS features.

[non]

This is something I said in the Gitter channel:

so my 2¢ for scala versions is that i think it makes sense to support at least 2.5 scala major versions. by which i am agreeing a bit with @alexandru -- dropping 2.10 support at 2.12.0 doesn't seem like a good plan, but dropping it by say 2.12.3 (or so) doesn't seem bad to me.

I'm not totally convinced that I think supporting 2.10 in perpetuity is important, but I will continue supporting it for awhile longer at least.

[milessabin]

@dwijnand @julien-truffaut @mpilquist ... could you elaborate on your 👎's? Is that an active dislike? Or just lack of interest? Or something else?

[dwijnand]

Because of the maintenance costs - I'd personally prefer Typelevel focus on pushing the language forward of the burning edge side, rather than spending (the precious, little, volunteered) effort on the legacy side.

[milessabin]

@dwijnand understood, but the trailing edge acts as a drag on the leading edge ... if we can move things along from the rear that will help keep things moving further forward.

I also suspect you're overestimating how much work would be involved in the backports I listed at the top. For the most part I think they'll be cherry-pick plus a small amount of fix up.

[alexandru]

Some organizations are very slow to upgrade, being very conservative, so I'm for supporting 2.10 in libraries (like Cats) for a while longer.

Back-porting features on the other hand should only be done if the effort is small. If there are volunteers here wanting to support a Typelevel Scala with back-ported features, my opinion is that for going forward the effort would be better spent on doing support and back-ports for Scala 2.11, because from my understanding this is the last major version that's compatible with Java 6 and this represents a much bigger barrier for adoption.

[larsrh]

With the current situation I'm a proponent of keeping 2.10 compatibility, for the reason @fommil alluded to. As soon as the SBT 1.0.x ecosystem is mature enough, I think it's fair to drop compatibility.

But I also agree with @alexandru that we shouldn't spend too much effort on this. If it's as simple as @milessabin said, then I'm all for it.

[mandubian]

I'm in favor of this technically, my main issue is that I fear companies using Scala 2.10.x will be reluctant to use another compiler like TLS saying "hey this is not official scala, it's risky"... So, if backporting & maintaining 2.10 TLS doesn't cost much, OK, if it requires lots of efforts, not worth it...
👍

[milessabin]

@mandubian I think that will be true for some. But some are stuck for no fault of their own.

[mdedetrich]

I did a thumbs down, but note that this is my person situation. I think that the maintenance cost of supporting Scala 2.10 is going to be higher than people suspect, and I also think this sets a bad precedent of supporting things for longer than they should be supported.

I agree with @alexandru comment here

Back-porting features on the other hand should only be done if the effort is small.

But my suspicion is that its not going to be a small effort

[mandubian]

@milessabin I understand that and that's why I'm for it globally... with a small down in case it costs too much to TL just for a few unlucky (or lazy) people...

[mpilquist]

Not much to say that hasn't already been said. Organizations should move to 2.11 or 2.12 or stick with the libraries and versions they are using now. 2.11 came out 3 years ago which I feel is enough time for organizations to have planned upgrades.

[milessabin]

@mpilquist this issue isn't meant to be a judgement on other organizations ... it's a question about what we want to do. There are plenty of people still stuck on 2.10.x for no fault of their own who I'd like to be able to support with shapeless. But then what about literal types? Do I branch to support 2.10? Or hold off on literal types for 2.12?

[alexandru]

@milessabin suppose you back-port those features to 2.10 and take advantage of those in Shapeless, would people still on Scala 2.10.6 be able to use (the compiled binaries of) Shapeless or would they have to upgrade to Typelevel Scala?

If Scala 2.10.6 remains compatible with Shapeless, that's cool, otherwise I think people not able to upgrade to 2.11 are also going to have some trouble upgrading to a Typelevel Scala 2.10. It might actually be more difficult politically speaking, since it's going to be considered an "unofficial" version.

[milessabin]

Suppose the alternative is that I just drop shapeless support for 2.10?

[alexandru]

I'm not sure, but it's possible that requiring a Scala 2.10 fork is equivalent with dropping support for 2.10.

This is just an opinion, maybe we should find some users stuck on 2.10 and ask if they'd use a fork.

[tpolecat]

I think @milessabin's suggestion of dropping shapeless support for 2.10 convinced me that back-porting is a good idea, especially if it's easy. But if we do this I think Typelevel should also make a statement that we expect users to phase out 2.10 use by $DATE (mid/end 2017?), so we're not on the hook for indefinite maintenance, or at least can say we gave fair warning.

[milessabin]

If we do this we should make it absolutely clear that it's on a "best effort" basis only and that noone should think that we're "on the hook" for anything.

[gruggiero]

I think that my current project is a perfect example of a forced situation.
We use Scala 2.10 because we are in a corporate environment with Cloudera Hadoop and Spark.
Cloudera supports only 2.10 for Spark 1.6. A beta for Spark 2.0 and Scala 2.11 is on the way but too late for us.
Installing a custom Spark compiled for 2.11 is out of the question.
A compiler is a different matter, as a binary compatibility would not force us to install something "unofficial" on their servers.
But if some runtime error happens, who will be involved? Typelevel for not having done a perfect compatibility? Lightbend for not having respected the "specifications" (whichever they are) in their compiler implementation? The manager for having approved such situation?
On the other hand, the faster the Scala ecosystem evolves, the faster the products will need to adapt.

[aisven]

We are interested in 2.11.

We are not interested in 2.10, but we understand if there are people that need it.

(On a side note, we are also very interested in a 3.x that does not give too much about backwards compatibility. After all, it is a new major version. Re-writes are an okay trade-of if the language gets even better and simpler. Large open-source projects like Spark and Akka can surely invest in such re-writes, too.)

[fommil]

if TLS 2.10 had the faster typeclass derivation, I'd definitely be interested. I still crossbuild everything for 2.10 - primarily because of sbt.