Versioning

[adamw]

Currently a non-trivial amount of projects use magnolia 0.17 (https://mvnrepository.com/artifact/com.propensive/magnolia/usages). Releasing a binary-incompatible 1.0 with the same package name, could lead to unnecessary problems in the ecosystem.

That's why what I'd propose is:

• use the package name magnolia1 for magnolia 1.0 (not ideal, but since magnolia is taken, we can't do much here). This will allow us to freely rename the methods as proposed in rename combine/dispatch to join/split #247, aligning both magnolia flavors (for scala2 and scala3). So to use magnolia you'd have to do import magnolia1.*
• release both magnolia for scala2 and scala3 using version 1.0. This will give us the opportunity to evolve both independently, and release binary-incompatible versions in the future.
• use the group id com.softwaremill.magnolia1_2 for magnolia-scala2, and com.softwaremill.magnolia1_3 for magnolia-scala3. This is inspired by the suffixes which are added to all scala artifacts anyway, but here we need to use them in group ids as well, not only in versions (magnolia-scala2 is still a completely different codebase than magnolia-scala3)
• while we're at it, rename the main branch to scala3 (and keep it default), and the legacy branch to scala2 (there's nothing legacy about the scala2 version)

What do you think?

TODO list:

• rename branches
• rename package in scala2
• rename package in scala3
• change group id in scala2, release 1.0 milestone
• change group id in scala3, release 1.0 milestone
• explain naming strategy in readme

[przemek-pokrywka]

Huge plus one 👍
We need more bold decisions like this in the ecosystem.

[joroKr21]

👍 in general - although I don' understand this part (not sure why it matters):

use the group id com.softwaremill.magnolia1_2 for magnolia-scala2, and com.softwaremill.magnolia1_3 for magnolia-scala3. This is inspired by the suffixes which are added to all scala artifacts anyway, but here we need to use them in group ids as well, not only in versions (magnolia-scala2 is still a completely different codebase than magnolia-scala3)

[LGLO]

👍 . Lets keep differences explicit and don't get trapped by JVM dependencies resolution.

[adamw]

👍 in general - although I don' understand this part (not sure why it matters):

The scala2 & scala3 flavors need to have different coordinates in maven. So we'd have:

"com.softwaremill.magnolia1_2" %% "magnolia" % "1.0.0" // scala2
"com.softwaremill.magnolia1_3" %% "magnolia" % "1.0.0" // scala3

[adamw]

Most of the changes are done - I'll publish new snapshots tomorrow, given nobody notices any problems :)

[adamw]

I mean milestones, not snapshots :)

[adamw]

All done, 1.0.0-M3 for scala3, and 1.0.0-M5 for scala2 released, using the new group ids.

[rtyley]

You've probably already considered this, but a consequence of this change has been bugging me, and I just wanted to get it down in words, and try to document what was bothering me:

Scala 3 artifacts can be used in Scala 2 projects (CrossVersion.for2_13Use3), and Scala 2 artifacts can be used in Scala 3 (CrossVersion.for3Use2_13) projects - although library maintainers aren't encouraged to make use of this, it is supposed to be an ok approach for end-user projects (eg a webapp might consume libraries from both Scala 2 & Scala 3).

If an end-user project uses two libraries that depend on Magnolia (eg tapir, Scanamo, etc), one built for Scala 2.x (depending on "com.softwaremill.magnolia1_2" %% "magnolia"), and the other built for Scala 3 (depending on "com.softwaremill.magnolia1_3" %% "magnolia") there will be a clash in the magnolia1 package namespace (different and incompatible classes with the same fully qualified name, like magnolia1.SealedTrait). I'm not sure what the severity of this might be - I guess it would lead to a (possibly quite confusing) compile-time IncompatibleClassChangeError?

In general, I think artifacts that have different group+artifact coordinates (modulo, in the case of Scala development, the scala-version portion of the artifact name) ideally shouldn't contain classes with identical package names, as there's always this risk of a namespace clash.

One possible way to get round this might be different package namespaces for the Scala 2 & Scala 3 versions of magnolia - eg magnolia1_2 & magnolia1_3 - matching what's happened to the group id. That would be quite similar to, eg, the approach taken by OkHttp going from version 2 to 3.

[joroKr21]

Scala 3 artifacts can be used in Scala 2 projects (CrossVersion.for2_13Use3), and Scala 2 artifacts can be used in Scala 3 (CrossVersion.for3Use2_13) projects

I don't think this works for macros

[dwijnand]

The second part does:

The Scala 2.13 compiler can only expand Scala 2.13 macros and, conversely, the Scala 3 compiler can only expand Scala 3 macros. The idea of mixing macros is to package both macros in a single artifact, and let the compiler choose between the two during the macro expansion phase.

This is only possible in Scala 3, since the Scala 3 compiler can read both the Scala 3 and the Scala 2 definitions.

https://docs.scala-lang.org/scala3/guides/migration/tutorial-macro-mixing.html

[adamw]

@rtyley that's a good point, though say you have a Scala 3 project and you decide to use a Scala 2-based library. Any usage of Magnolia within that library will fail, as the macro just won't work. And I think usages of Magnolia within libraries are to expose typeclass generation for end-user types, not to use them internally. So I think in the end, you have to use the library version dedicated to your Scala version.

If I understand correctly what @dwijnand is quoting, you could package two macros in a single jar and have the compiler decide which one to use. That won't work here as well, as we have different (even if only slightly) definitions of SealedTrait and CaseClass (among others), so these two aren't equivalent. And this will diverge, as we add support for more scala3-specific types.