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

Open
milessabin opened this Issue Nov 3, 2016 · 31 comments

Comments

Projects
None yet
@milessabin
Member

milessabin commented Nov 3, 2016

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).

@milessabin milessabin added the question label Nov 3, 2016

@adelbertc

This comment has been minimized.

Show comment
Hide comment
@adelbertc

adelbertc Nov 3, 2016

Member

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: functional-streams-for-scala/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

Member

adelbertc commented Nov 3, 2016

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: functional-streams-for-scala/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

This comment has been minimized.

Show comment
Hide comment
@milessabin

milessabin Nov 3, 2016

Member

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

Member

milessabin commented Nov 3, 2016

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

@nafg

This comment has been minimized.

Show comment
Hide comment
@nafg

nafg Nov 3, 2016

Is right-biased Either source-compatible?

nafg commented Nov 3, 2016

Is right-biased Either source-compatible?

@milessabin

This comment has been minimized.

Show comment
Hide comment
@milessabin

milessabin Nov 3, 2016

Member

@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.

Member

milessabin commented Nov 3, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@milessabin

milessabin Nov 3, 2016

Member

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

Member

milessabin commented Nov 3, 2016

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

@nafg

This comment has been minimized.

Show comment
Hide comment
@nafg

nafg Nov 3, 2016

@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)

nafg commented Nov 3, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@milessabin

milessabin Nov 3, 2016

Member

@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.

Member

milessabin commented Nov 3, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@milessabin

milessabin Nov 3, 2016

Member

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

Member

milessabin commented Nov 3, 2016

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

@rossabaker

This comment has been minimized.

Show comment
Hide comment
@rossabaker

rossabaker Nov 3, 2016

Member

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 👍.

Member

rossabaker commented Nov 3, 2016

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 comment has been minimized.

Show comment
Hide comment
@tpolecat

tpolecat Nov 3, 2016

Member

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.

Member

tpolecat commented Nov 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@fommil

fommil Nov 3, 2016

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.

fommil commented Nov 3, 2016

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 comment has been minimized.

Show comment
Hide comment
@non

non Nov 3, 2016

Member

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.

Member

non commented Nov 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@milessabin

milessabin Nov 3, 2016

Member

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

Member

milessabin commented Nov 3, 2016

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

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Nov 3, 2016

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.

dwijnand commented Nov 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@milessabin

milessabin Nov 3, 2016

Member

@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.

Member

milessabin commented Nov 3, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@alexandru

alexandru Nov 4, 2016

Member

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.

Member

alexandru commented Nov 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@larsrh

larsrh Nov 4, 2016

Member

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.

Member

larsrh commented Nov 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mandubian

mandubian Nov 4, 2016

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...
👍

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

This comment has been minimized.

Show comment
Hide comment
@milessabin

milessabin Nov 4, 2016

Member

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

Member

milessabin commented Nov 4, 2016

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

@mdedetrich

This comment has been minimized.

Show comment
Hide comment
@mdedetrich

mdedetrich Nov 4, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@mandubian

mandubian Nov 4, 2016

@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...

@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

This comment has been minimized.

Show comment
Hide comment
@mpilquist

mpilquist Nov 4, 2016

Member

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.

Member

mpilquist commented Nov 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@milessabin

milessabin Nov 4, 2016

Member

@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?

Member

milessabin commented Nov 4, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@alexandru

alexandru Nov 4, 2016

Member

@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.

Member

alexandru commented Nov 4, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@milessabin

milessabin Nov 4, 2016

Member

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

Member

milessabin commented Nov 4, 2016

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

@alexandru

This comment has been minimized.

Show comment
Hide comment
@alexandru

alexandru Nov 4, 2016

Member

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.

Member

alexandru commented Nov 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tpolecat

tpolecat Nov 4, 2016

Member

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.

Member

tpolecat commented Nov 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@milessabin

milessabin Nov 4, 2016

Member

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.

Member

milessabin commented Nov 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gruggiero

gruggiero Nov 8, 2016

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.

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.

@sourcekick

This comment has been minimized.

Show comment
Hide comment
@sourcekick

sourcekick Nov 11, 2016

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.)

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

This comment has been minimized.

Show comment
Hide comment
@fommil

fommil Jan 19, 2017

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.

fommil commented Jan 19, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment