Dependency status:
What was missing? Also, maybe it doesn't make sense to release for M3 any more when M4 is the current one and M5 is already on the radar.
It just isn't/wasn't part of our travis release process.
We can't go to M4 yet because Akka is not on M4 yet (https://github.com/akka/akka/issues/25105), as soon as it is we should try switching indeed.
Can we repurpose this for 10.1.5?
This is currently blocking upgrading Play to Akka HTTP 10.1.5: https://github.com/playframework/playframework/pull/8597
Maybe we set the wrong expectations when we published the 2.13.0-M3 version of 10.1.0. In fact, there are no guarantees that we will or will not continue publishing releases for Scala milestone releases, especially not for any that are outdated since months (and that is missing all the big changes from M4).
I guess I just made the release back then for 10.1.0 because it was easy enough to do. However, I didn't follow up to make it part of our CI and release infrastructure. So, we don't run any tests or PR validation on 2.13.0-M3 currently. We don't know if the release process still works for 2.13.0-M3, etc. In fact, I'm not sure we even should have tracked M3, it's certainly not free to do so.
So, I could invest a bit of time to see what's missing but then the release would still be untested etc. It doesn't seem to be a particular useful thing to spend time on right now (e.g. compared to getting Akka compile with 2.13.0-M5 to make some actual progress).
I wonder, how can publishing a version for an outdated Scala milestone release be a blocker for Play? Would anyone actually use it? Are there other reasons I'm missing?
@jrudolph from Play/Lagom point of view it's perfectly fine that akka-http 10.1.5 is not published for 2.13.0-M3 or 2.13.0-M4. The problem is not having a release for _any_ version of 2.13.0-Mx.
In Play, the travis job to build play with some milestone of 2.13.0 is useful to detect and fix any issues so that releasing support for 2.13.0 may happen not later than scala 2.13.0 being out.
Given the cause is actually https://github.com/akka/akka/issues/25105 (and other upstream depenendencies which Play also depends on) I think we're better off disabling the travis job in https://github.com/playframework/playframework/pull/8597.
OK, I guess upgrading Akka HTTP and dropping Scala 2.13 validation is the better of the two remaining options.
The problem is not having a release for _any_ version of
2.13.0-Mx.
Exactly, we should try to track them more closely but as M4 needed some significant porting overhead, we are behind.
In Play, the travis job to build play with some milestone of
2.13.0is useful to detect and fix any issues so that releasing support for2.13.0may happen not later than scala2.13.0being out.
I agree, that would also our goal for tracking 2.13 milestones. But then we still need to keep on track, just testing against M3 stops being useful after a while :)
I think we're better off disabling the travis job
Thanks!
just testing against M3 stops being useful after a while
No it doesn't, it continues to ensure that the codebase compiles and tests pass on Scala 2.13.0-M3.
Hi,
@jrudolph thanks for the clear update here.
Well, we had a similar plan when adding support for M3, but with the difference that we made it part of our release process and our testing in Travis. The idea was to keep the pace with Scala 2.13 milestone releases and ensure we can release Play 2.7 with Scala 2.13 support (even if it was for milestones).
Of course, priorities changes and we were not able to move to M4 although most of the Play standalone projects are already there (https://github.com/playframework/play-json/pull/169 and https://github.com/playframework/twirl/pull/180 play-ws is blocked on by https://github.com/akka/akka/issues/25105 too as you see here https://github.com/playframework/play-ws/issues/274) thanks to the community.
I have the impression of disabling the Travis job without a clear plan on what to do, not just for Akka but Play also, is a step back. We can take it, but what are the implications? When will it be added back? Can we do a patch release later support the most recent milestone? Is supporting M4/M5 and adding them to the release process a priority for Akka team?
As @dwijnand said, having it on our testing/release process is valuable to ensure the changes in Play code base are fine with Scala 2.13. I would prefer not to remove that. Are there other alternatives?
just testing against M3 stops being useful after a while
No it doesn't, it continues to ensure that the codebase compiles and tests pass on Scala 2.13.0-M3.
My point is that M3 (when compared to M5) is only a very vague predictor of the changes necessary to make any project compile with 2.13 final in the end. You will have to do some work anyway and catching the things necessary for 2.13.0-M3 will probably be 10% of the final changes necessary to make the project compile with the final version (I might guess that wrong). On the other hand, maintaining compatibility with early milestones does not come for free and we haven't done the work yet.
I have the impression of disabling the Travis job without a clear plan on what to do, not just for Akka but Play also, is a step back.
I'd say the plan is to move to 2.13.0-M5 asap. For the time being you could just pin Akka Http to 10.1.4 for the 2.13.0-M3 version for the time being.
the things necessary for 2.13.0-M3 will probably be 10% of the final changes necessary
agree, but the good news is that moving to M5 (or even M4) should get you 80% of the way to 2.13.0 final. the new collections landing in M4 is the thing
let's (collectively) try and get everything on M5 as soon as we reasonably can. hopefully we can get ScalaCheck+ScalaTest+specs2 out the door for M5 soon and then the floodgates can open.
It seems only Akka is missing for an M5 release.
Akka 2.5.19 has now been published for 2.13.0-M5
akka-http artifacts for M5 are on Maven Central: https://repo1.maven.org/maven2/com/typesafe/akka/akka-http_2.13.0-M5/10.1.7/
is there a reason for this ticket to stay open?
I think it was released out-of-band of the master branch, probably on the #2298 branch?
I think it was released out-of-band of the master branch, probably on the #2298 branch?
Yes, indeed. With #2298 merged we will include 2.13.0-M5 in the regular release process from now on.
I'm closing this for now. There's nothing special in the release process for 2.13.0-M5 but we should keep an I on what's happening when we make the next release.