Drop 2.12 support about pekko HOT 25 OPEN

Is it odd to suggest that dropping support should align with Scala center end-of-life of a version?

Scala 2.12.x itself would quite conceivably have been EOLed by now if it weren't for commercial sponsorship for its continued maintenance.

So you can argue that for a pure OSS effort such as Pekko to drop 2.12 is actually consistent with the approach that Lightbend and the Center have taken with our stewardship of Scala 2.12.x — namely, yes if commercially funded, otherwise perhaps no.

from pekko.

I'd like to invite everyone to view issues like this from a community perspective. The whole first goal of this project is to preserve the existing status of the open source project and set up administrative structures to enable broader participation. So, there's no attempt to drop 2.12 from the initial release.

From there on, we'll see where it will go. In any case, it will require offers from the community to take on issues they see as pressing. Maintaining such a big project really is difficult and time consuming. I created these items originally, to show which current properties of the existing codebase make evolution more difficult (in this case, making sure everything works on at least 3 Scala versions can be a significant drain in productivity and often caused bugs).

IMO, the situation is pretty good even for 2.12 support: there will be an initial release supporting 2.12 and the basic organizational structures are set up that will allow the community to backport pressing issue to that first release branch and have some hope to get them released.

from pekko.

In my opinion I would advocate for supporting 2.12 until it becomes painful to maintain it, then we can drop it.

IMO, pain does not really work as a good metric because the pains will usually be small but consistent. E.g. just having that third version in the test and release matrix, it will add 50% more cost, possibility for flaky tests, missed test coverage, extra reasons for mima to fail etc. On the other hand, 2.13 has been released more than 3 years ago and has been super stable since a long while. There's little reason to stay on 2.12, so why should we?

from pekko.

Still on 2.12 ✅

Admittedly, we're not on the latest Akka either and we sure had the intention to move Scala 2.13 before doing so.

We're blocked from doing that before, but metals/VSCode is our route forward now.

Anyhow, am I wrong to state it's an Apache "thing" to support fairly "mature" runtimes?

Is it odd to suggest that dropping support should align with Scala center end-of-life of a version?

from pekko.

Even if we decide to drop Scala 2.12 support for http module, we could keep it for other modules where the maintenance would be less of an issue.

from pekko.

And on the other hand, migrating from Akka to Pekko will be more effort/risker than upgrading from Scala 2.12 to Scala 2.13 from my experience.

from pekko.

I agree, it should be good enough to support the last two major versions

from pekko.

Yes, Scala 3.3 lts is near the corner too.

from pekko.

I did do some research before writing that response, but it seems like these things aren't communicated very openly. (Till what you just wrote).
A published timeline for such things would really be helpful to base a decision on.
If not EOL, call it deep maintenance.

If it where Java, I'd think you'd target lts's and could start considering dropping 8.

from pekko.

I feel that many people are still using version 2.12, including me

Still on 2.12

from pekko.

To get more facts, what is preventing you from upgrading to Scala 2.13?

from pekko.

I would disagree with dropping 2.12, even though technically speaking with Scala 3 its outside of the "latest 2 stable versions", adoption of Scala 3 is really slow and I wouldn't say its controversial that a lot of current Akka users would still be using and/or expecting 2.12 support.

In my opinion I would advocate for supporting 2.12 until it becomes painful to maintain it, then we can drop it.

from pekko.

In my opinion I would advocate for supporting 2.12 until it becomes painful to maintain it, then we can drop it.

It is painful for pekko-http as soon as we merge the Scala 3 branch.

from pekko.

It is painful for pekko-http as soon as we merge the Scala 3 branch.

I guess this would be because we would rely on Scala 3 to provide Scala 2.13 support so we would only have a single source directory?

from pekko.

It is painful for pekko-http as soon as we merge the Scala 3 branch.

I guess this would be because we would rely on Scala 3 to provide Scala 2.13 support so we would only have a single source directory?

Because, we would have to support hacky support structures to make it work at all and because of the general problems and costs of supporting an extra version in such a big project.

from pekko.

There's little reason to stay on 2.12, so why should we?

I can't answer this, I have no idea how much people are currently running akka-http on 2.12 which could cause a problem or whether we even care.

Because, we would have to support hacky support structures to make it work at all and because of the general problems and costs of supporting an extra version in such a big project.

Yeah the reason I asked this is whether we have pekko-http already has separate source folders for scala-2.13+/scala-2.13-. I just had a look and akka-http-core appears to have such a structure. My original assumption is that with Scala 3 support, one would have to have a scala-2.13- along with a scala-3 folder and hence there wouldn't be that much extra effort as long as subtle things don't change in core of pekko-http since the source for both Scala 2.12 and 2.13 seems to be the same (this is goes back to the "pain" part before)?

If it was just a scala-3 folder which would back compile to Scala 2.13 then that to me a much stronger argument since the mere presence of other source folders aside from scala-3 is to me the main complicating factor but I may be wrong here (and also my tolerance for "pain" might be higher).

The other part which might influence this that just came to mind is the rest of the ecosystem as a whole. For example Kafka currently supports 2.12 and 2.13, I am not sure if they plan to support 2.12/2.13 and 3 when scala 3 is ready but since we have connectors (i.e. pekko-connectors-kafka) it might be problematic that Kafka itself is supporting older versions than pekko itself but I may be exaggerating things here. Spark is another library that also is currently support Scala 2.12.

from pekko.

Scala 2.13 has compiler flags to support certain Scala 3 syntax. Scala 3.0 supports both old and new styles, but newer Scala 3 versions will going to drop that. So mid to long term only Scala 2.13 in addition to Scala 3 will be viable to support without cloning the code base for Scala 2.12.

from pekko.

Well, before we had standardized on ScalaIDE, which meant that we were stuck on Scala 2.12 since 2018 😔

We've started adopting VSCode/Metals, but that setup still needs plenty of refinement, so only a couple of services use that already. It does look like this will be our way forward to Scala 2.13 and up.

But yes, it's unlikely that we bother to adopt Pekko before we can switch to 2.13, so I concur with many of the above statements.

To generalize, I actually think it's fair to consider dropping 2.12.

I just notice that Scala 2.12 isn't that dead yet. There's the Kafka example from above and afaik, writing an SBT plugin is also still 2.12.x.

from pekko.

I just notice that Scala 2.12 isn't that dead yet. There's the Kafka example from above and afaik, writing an SBT plugin is also still 2.12.x.

The main thing I am afraid of is jumping the gun when dropping 2.12 support even though a lot of other major Scala OS projects still support it (for various reasons), so at least in my opinion the optics of dropping 2.12 support in light of the rest of the Scala ecosystem wouldn't look the best. The only counter examples I can think of are projects like Flink, who have much bigger pains in supporting multiple Scala versions due to them using Maven (and in any case they are trying to completely phase out Scala as we speak so they aren't the best example to use).

Heck, even as you pointed out with SBT still on 2.12, unless SBT 2.x comes out then historically SBT kind of creates a lower floor for what is reasonable to support in terms of Scala open source libraries (at least if we are dealing with Scala libraries which are used for sbt plugins). So I would in fact say that 2.12 is far from dead, in fact its very much as alive as 2.13 is considering at least in the Scala space almost every major OS library I can see still supports 2.12.

Ultimately I think we should formalise this as a process and also try and rationally quantify what the "pain" is.

from pekko.

This is going to be contentious. I think we would need a community vote before proceeding.

from pekko.

This is going to be contentious. I think we would need a community vote before proceeding.

Agreed.

Also to add more to the debate, when pekko-http gets released I plan on adding pekko-http support to scalaxb and since scalaxb is an sbt plugin (sbt plugins are built with Scala 2.12 only) it would essentially mean that scalaxb would be stuck with pekko-http 1.0.x series of updates.

While this may not be the end of the world since sbt 1.x will be around for a while it would essentially mean that scalaxb's pekko-http backend wouldn't get new feature requests since that will only be for the 1.1.x series.

from pekko.

I think we should start by agreeing how long we will maintain the 1.0.x release lines. If we agree to make critical fixes to 1.0.x release lines, then I think we can make big changes in 1.1.x lines. People who can't use 1.1.x release lines because of the changes can continue to use 1.0.x releases.

from pekko.

I think we should start by agreeing how long we will maintain the 1.0.x release lines.

I would rephrase the question by asking how much effort rather than how long. Since the agreement of 1.0.x is only backport of security/critical fixes we could "support" 1.0.x for a while assuming that these fixes are trivial to backport. If that stops becoming the case then we can consider dropping 1.0.x support.

The reasoning behind this is that our treatment from 1.0.x is special in the sense that its designed to be a bridge for people on Akka 2.6 and in this regard its not a "normal" release branch, i.e. the reason for its special status is the Akka fork. Hence our "normal" release branch is essentially 1.1.x, which means that major changes like dropping 2.12 should happen in 1.2.x. It also means that are incentivised to "support" 1.0.x as long as we can, because of that bridge status.

Also note that in terms of supporting Scala 2.12, with the changes I did in #281 and the subsequent related PR's, the maintenance cost in supporting 2.12 is largely trivialised.

from pekko.

I plan on adding pekko-http support to scalaxb and since scalaxb is an sbt plugin (sbt plugins are built with Scala 2.12 only

Scalaxb SBT plugin is just generating code. It does not need to run pekko-http in scala 2.12...

from pekko.

Scalaxb SBT plugin is just generating code. It does not need to run pekko-http in scala 2.12...

Yes I know but testing it within context of an sbt plugin its easier to test/implement if it supports Scala 2.12, we had similar issues with pekko-grpc sbt plugin (which also just generates code).

from pekko.