New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 2.11.10 #359

Closed
adriaanm opened this Issue Apr 4, 2017 · 17 comments

Comments

Projects
None yet
6 participants
@adriaanm
Member

adriaanm commented Apr 4, 2017

Scala 2.11.9 (see #330) contained a critical regression in binary stability (due to scala/scala#5664), which is why we are reverting the binary incompatible commits of that PR in scala/scala#5821 and releasing 2.11.10 (this week) without announcing 2.11.9.

Additionally, #352 is fixed by scala/scala#5828 (thanks @xuwei-k and @sjrd).

These are the only changes with respect to 2.11.9

@adriaanm adriaanm referenced this issue Apr 4, 2017

Closed

Release 2.11.9 #330

@adriaanm

This comment has been minimized.

Show comment
Hide comment
@adriaanm

adriaanm Apr 6, 2017

Member

Bytecode diff due diligence

Compiling the 2.11.10 code base with 2.11.8 and itself yields the following diff in javap -vp output: https://gist.github.com/adriaanm/da437b85be0c5e3c6dc0269443a4e63f. Two differences:

Sadly, there was no additional diff between 2.11.8 and 2.11.9, so I'm not sure how much this tells us.

Member

adriaanm commented Apr 6, 2017

Bytecode diff due diligence

Compiling the 2.11.10 code base with 2.11.8 and itself yields the following diff in javap -vp output: https://gist.github.com/adriaanm/da437b85be0c5e3c6dc0269443a4e63f. Two differences:

Sadly, there was no additional diff between 2.11.8 and 2.11.9, so I'm not sure how much this tells us.

@xeno-by

This comment has been minimized.

Show comment
Hide comment
@xeno-by

xeno-by Apr 6, 2017

Member

@adriaanm Paradise 2.11.10 works: scalamacros/paradise@3bc2bd2.

Member

xeno-by commented Apr 6, 2017

@adriaanm Paradise 2.11.10 works: scalamacros/paradise@3bc2bd2.

@adriaanm

This comment has been minimized.

Show comment
Hide comment
@adriaanm

adriaanm Apr 7, 2017

Member

I also checked the full bytecode of the 2.11.8/10 libraries compiled with their respective compiler: https://gist.github.com/adriaanm/c72ae563f7784a15e1ea75799b2daae9

I think 2.11.10 is ready to go.

Member

adriaanm commented Apr 7, 2017

I also checked the full bytecode of the 2.11.8/10 libraries compiled with their respective compiler: https://gist.github.com/adriaanm/c72ae563f7784a15e1ea75799b2daae9

I think 2.11.10 is ready to go.

@adriaanm

This comment has been minimized.

Show comment
Hide comment
@adriaanm

adriaanm Apr 7, 2017

Member

Tags pushed and staging repo promoted. Will publish release notes and announce next week

Member

adriaanm commented Apr 7, 2017

Tags pushed and staging repo promoted. Will publish release notes and announce next week

@xeno-by

This comment has been minimized.

Show comment
Hide comment
Member

xeno-by commented Apr 8, 2017

@sjrd

This comment has been minimized.

Show comment
Hide comment
@sjrd

sjrd Apr 8, 2017

Member

Scala.js 0.6.15 for Scala 2.11.10 has been released too.

Member

sjrd commented Apr 8, 2017

Scala.js 0.6.15 for Scala 2.11.10 has been released too.

@xeno-by

This comment has been minimized.

Show comment
Hide comment
@xeno-by

xeno-by Apr 8, 2017

Member

Pre-release builds of meta 1.7.0 and meta paradise 3.0.0-M8 have been built against 2.11.10 without problems.

Member

xeno-by commented Apr 8, 2017

Pre-release builds of meta 1.7.0 and meta paradise 3.0.0-M8 have been built against 2.11.10 without problems.

@adriaanm

This comment has been minimized.

Show comment
Hide comment
@adriaanm

adriaanm Apr 12, 2017

Member

Well, my embarrassment just went up another notch. The 2.12 community build found another issue with my apply/unapply fix. (Point well taken, universe, point well taken.)

I should probably backport my 2.12 fix for scala/bug#10261 to 2.11.x and release 2.11.11 once we're sure the 2.12 community build is all good. I really feel bad for wasting everyone's time and burning a few version numbers in the process, but it's probably the right thing to do.

What do you think?

Member

adriaanm commented Apr 12, 2017

Well, my embarrassment just went up another notch. The 2.12 community build found another issue with my apply/unapply fix. (Point well taken, universe, point well taken.)

I should probably backport my 2.12 fix for scala/bug#10261 to 2.11.x and release 2.11.11 once we're sure the 2.12 community build is all good. I really feel bad for wasting everyone's time and burning a few version numbers in the process, but it's probably the right thing to do.

What do you think?

@hepin1989

This comment has been minimized.

Show comment
Hide comment
@hepin1989

hepin1989 Apr 12, 2017

I suggest take a little longer time and exhaustive test to make sure/wait it matured.
No one never done all goods:)

hepin1989 commented Apr 12, 2017

I suggest take a little longer time and exhaustive test to make sure/wait it matured.
No one never done all goods:)

@sjrd

This comment has been minimized.

Show comment
Hide comment
@sjrd

sjrd Apr 12, 2017

Member

What about reverting those changes altogether? I mean, it's basically a language change, that shouldn't be sneakily done in the last minor version of 2.11.x. Maybe that's the point the universe is trying to make? ;)

Member

sjrd commented Apr 12, 2017

What about reverting those changes altogether? I mean, it's basically a language change, that shouldn't be sneakily done in the last minor version of 2.11.x. Maybe that's the point the universe is trying to make? ;)

@som-snytt

This comment has been minimized.

Show comment
Hide comment
@som-snytt

som-snytt Apr 12, 2017

It's pretty cool that 2.11 will now go all the way to eleven.

It's pretty cool that 2.11 will now go all the way to eleven.

@densh

This comment has been minimized.

Show comment
Hide comment
@densh

densh Apr 12, 2017

I second @sjrd's concern. Can we still revert this altogether in 2.11.x ?

densh commented Apr 12, 2017

I second @sjrd's concern. Can we still revert this altogether in 2.11.x ?

@adriaanm

This comment has been minimized.

Show comment
Hide comment
@adriaanm

adriaanm Apr 12, 2017

Member

I understand your concern, but we'd really like this change to be in both 2.11 and 2.12. It's a common (enough) pattern, and is currently compiled in a surprising (silently) wrong way.

Here's one example of where the framework's validation in the apply method won't be called if you use a case class: https://github.com/akka/akka-http/blob/master/akka-http-core/src/main/scala/akka/http/scaladsl/model/headers/headers.scala#L90-L109

Member

adriaanm commented Apr 12, 2017

I understand your concern, but we'd really like this change to be in both 2.11 and 2.12. It's a common (enough) pattern, and is currently compiled in a surprising (silently) wrong way.

Here's one example of where the framework's validation in the apply method won't be called if you use a case class: https://github.com/akka/akka-http/blob/master/akka-http-core/src/main/scala/akka/http/scaladsl/model/headers/headers.scala#L90-L109

@adriaanm

This comment has been minimized.

Show comment
Hide comment
@adriaanm

adriaanm Apr 12, 2017

Member

I would agree it's a language implementation change, but not a language change. The code in Namers always had a comment that said an apply/unapply wouldn't be added if it would cause a conflict (like the copy method, where this logic was implemented). That logic was not implemented, so the compiler would crash if there was a conflict due to different levels of accessibility (or, silently emit the overriding synthetic method instead of favoring the existing one).

Now -- modulo my mistakes that should hopefully be fixed -- it is implemented, and I'd say it matches programmer intuition.

Member

adriaanm commented Apr 12, 2017

I would agree it's a language implementation change, but not a language change. The code in Namers always had a comment that said an apply/unapply wouldn't be added if it would cause a conflict (like the copy method, where this logic was implemented). That logic was not implemented, so the compiler would crash if there was a conflict due to different levels of accessibility (or, silently emit the overriding synthetic method instead of favoring the existing one).

Now -- modulo my mistakes that should hopefully be fixed -- it is implemented, and I'd say it matches programmer intuition.

@adriaanm

This comment has been minimized.

Show comment
Hide comment
@adriaanm

adriaanm Apr 12, 2017

Member

As a compromise, here's a PR that backports the latest issue revealed by the community build, and also puts the whole change under -Xsource:2.12: scala/scala#5846

Member

adriaanm commented Apr 12, 2017

As a compromise, here's a PR that backports the latest issue revealed by the community build, and also puts the whole change under -Xsource:2.12: scala/scala#5846

@adriaanm

This comment has been minimized.

Show comment
Hide comment
@adriaanm

adriaanm Apr 12, 2017

Member

It's pretty cool that 2.11 will now go all the way to eleven.

And we have a title for the release notes :-)

Member

adriaanm commented Apr 12, 2017

It's pretty cool that 2.11 will now go all the way to eleven.

And we have a title for the release notes :-)

Mygod added a commit to shadowsocks/shadowsocks-android that referenced this issue Apr 13, 2017

Update scala to 2.11.10
It seems there will be 2.11.11 coming out soon however.

Source:
scala/scala-dev#359 (comment)

@adriaanm adriaanm closed this Apr 13, 2017

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