[Meta Thread] Post 1.2 Roadmap

[kailuowang]

There has been some discussion around 2.0, 3.0 here and there. Let's consolidate them here.

Option 1:

• 1.x: continue current supports and BC
• 2.0: binary compatible with 1.x on Scala 2.12, still supports 2.11, drops 2.10
• 3.0: break with 1.x and 2.x, Supports 2.12 and 2.13, drops 2.11, support which could potentially use a different group name and namespace to avoid conflicts.

Option 2:

• 1.3: binary compatible with 1.x on Scala 2.12 and Scala 2.11, drops support for Scala2.10
• 1.5: binary compatible with 1.x on Scala 2.12, drops supports 2.11
• 2.0: break with 1.x, Supports 2.12 and 2.13, which could potentially use a different group name and namespace to avoid conflicts.

Option 3:

• 1.? Once Scala 2.13.1 is ready, we start to separate code into 2.12- and 2.13 code folder. We can introduce changes to the 2.13 codebase but also make sure they are source compatible, so that project that cross builds can easily compile against the new 2.13 build of Cats. This way users can start to enjoy the new optimization when they are on 2.13 but maintain compatibility on 2.12 and 2.11. This might be the least disruptive way to introduce changes enabled by the 2.13 feature.

• 2.0 break with 1.x, Supports 2.12 and 2.13, which could potentially use a different group name and namespace to avoid conflicts.

Obviously, there are more options. Let's write them done first.

[johnynek]

if we use a different group name, we should use a new package as well, otherwise we have identically named classes in different maven groups which leads to pain.

[kailuowang]

update from https://issues.apache.org/jira/browse/SPARK-14220, looks like that the next release of Spark might be going to be on 2.12

[LukaJCB]

If the timing of the next major Cats release is still a year from 1.0, will we let go of 2.11? That would be in december, which seems a tad bit premature, or no?

[johnynek]

I like option 1: cats 2.0 is still binary compatible for 2.12, but still publish for 2.11 and 2.13.

[LukaJCB]

In Scenario 1, what would be the timeline for 3.0? Release at the same time as 2.0?

[johnynek]

I think we should take a step back. I think the timeline should come after the goals.

Maybe it is time to make a clearer plan for 2.0 and 3.0. A tracking issue with a list of changes desired would be good.

I would also advocate against being too concerned with warts. I don’t like them either but I can hold my nose to avoid putting a migration cost on people.

Lastly, it would be interesting to think about compatibility metrics. When we break compatibility we still want to minimize the differences and hopefully even fewer source incompatibilities.

[LukaJCB]

Sorry pressed close by mistake.

One thing that I really really want to see is newtypes for all of our data types, I had some benchmarks and they all pointed to enormous performance gains. We could easily pull that off in a fully source compatible way, but even in 2.12 I fear it won't be binary compatible. :/

[LukaJCB]

As to a list of changes that are incompatible, I only see two right now (three if we count removing Future instances) if we look at the issues: https://github.com/typelevel/cats/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.0+label%3A%22API+Breaking%22

[kailuowang]

Here is what I am thinking IRT goals and timeline and I probably missed a bunch of things that should've been taken into consideration.

2.0 (maintains BC with 1.x on 2.12),

Goals:

• Move a bunch of methods from those shim traits back to the original intended traits
• Take full advantage of the better BC on 2.12 going forward.

Timeline:

We can probably target it to be released a bit after Spark on 2.12 is released.

3.0

Goals:

• Refactor to take advantage of newtype/opaque type
• Fixes warts that requires sources breaking changes. issues identified so far

Timeline:

We need to keep in mind that once 3.0 is released, following 3.x should all be BC with it, so we need some way to battlefield test all these changes before 3.0 release. I see two plans:

1. a new cats-new project that provides all the re-written data types using newtype/opaque type, people can use it alone with the type classes in Cats 2.0, we evolve this for some time before we merge it into Cats 3.0
2. start a Cats 3.0 branch and migrate data types to newtypes/opque types, start to release milestone releases and let it evolve for a while before 3.0.0 release. This is easier for us but a bit harder for users, since they have to migrate to the new type classes too (which will be under a new package name)

[LukaJCB]

Will 2.0 still support Scala 2.11 in that scenario @kailuowang? :)

[kailuowang]

@LukaJCB I'd say yes. I don't see much cost of keeping it. Do you?

[LukaJCB]

Fully agreed, just wanted to make sure :)

[ceedubs]

I just wanted to chime in and say that I completely agree with @kailuowang's proposed 2.0 plan.

As for 3.0, I'm less sure, because it's early in the days of opaque types and the last that I knew there wasn't One True Newtype for Scala.

[kailuowang]

I just realized that if we have 2.0 to continue support 2.11, the binary breaking change releases on 2.11 might render cats 2.x impractical to use on 2.11. It might be better off for 2.11 users if we either drop 2.11 altogether or we backport 2.0 changes into a 1.x branch and maintain it for another year or so. In another sentence, we probably shouldn't release binary breaking cats. 2.x on 2.11.

[johnynek]

@ceedubs I assume we are talking about sip 35 opaque types which supposedly are coming behind a flag on 2.13 and standard in 2.14 (who knows, maybe could be backported to 2.12 in a compiler plugin).

I hope we can be very conservative with wart cleaning. Warts happen and each source and binary incompatibility is an opportunity to strand a user on an old version (look at how long Spark waited to upgrade to 2.12).

Part of being a core library is appropriately weighting stability. I don’t have a perfect answer but I hope we bias to stability and only change break source compatibility to fix important correctness or performance issues.

[larsrh]

Since 2.0 has been out for a while, this issue is no longer relevant.

[joroKr21]

Dare I suggest cats 3.0 be only Scala 3.x+?

[rossabaker]

The thought of Cats 3 makes a lot of us chasing Scala 3 and Cats Effect 3 want to curl up under our desks, but it is important to have a roadmap. I think that's a separate issue (or discussion) that should result in a doc on the site.

[kailuowang]

I drafted an evolution plan last year. @LukaJCB and I advocated that we only bring break binary compatibility changes to new scala major version (3.0 now).
I still believe that this is the only viable path for cats to evolve.

https://gist.github.com/kailuowang/81eafd4f6b0defa36d3ea179105f0bf2

[larsrh]

Let's discuss this in a new thread (#3757).