Hi,
Let’s add to the Scala development guarantees | The Scala Programming Language some recommendations about library naming.
This can be one phrase:
“If you need to publish two versions of your library, one for the LTS-line and one for the Next line, we recommend publishing LTS version as default and the Next version with ‘-next’ suffix added to the library name”, I.e. “com.example::my-library:0.1” target LTS-line and “com.example::my-library-next:0.1” target the Next line.
Is version of your library cross compiled using Scala Next features? If no, there is no point in cross publishing.
For libraries it’s recommended to use single Scala 3 versioning line, typically it’s LTS unless you require specific features available only in Next. Sticking to LTS simply allows you attract the most users without enforcing minimal version of Scala 3 on them.
If each of them is using a different set of features, then I’d recommend publishing only for Scala Next until next LTS series is published.
(By the way, I can’t understand what “cross-compiled” means. Technically, cross-publishing for 3.3x and 3.6x is impossible because we will receive the same artifact names; it’s why I write about different suffixes). The absence of cross-publishing also makes cross-compilation non-existent. Is it not ?
There is a situation where we need two versions. [Example - support of new constructions in macroses or use of API, which was experimental before].
If you need to publish two versions of your library,
If means that it is not for all libraries.
We can add a sentence, if you think that one if is not enough:
“Most libraries should be published only for LTS version. For cases where you need to publish two versions … ame text”.
In general, I can accept any policy, but the main issue is that it should be explicitly written.
Imagine the person who writes a new library with dependencies. Now, without looking at the sources of dependencies, it is impossible to determine if the dependencies force the new library to be next-only or if it can be used with LTS. Having a convention that ‘normal’ library names for LTS will eliminate situations when I write a set of dependencies and, during first build, see a message
This TASTy file was produced by a more recent, forwards incompatible release.
[error] To read this TASTy file, please upgrade your tooling.
It’s exactly what happened to me before I opened this topic.
We can get this information from Scaladex, see example under Full Scala Version
Now maybe, we should extend build tools to inform about this kind of problems when resolving dependencies? It should not be hard, we basically only need to check the .pom file content.
We already have the checks (at least in sbt) introduced for SIP-51 where build tools would warn if Scala 2 stdlib is older then version of compiler. We should extended these for Scala 3 series
I’m against special suffixes for LTS / Next version, both series are regular Scala versions. You, as an author should decide what the minimal supported version, similarly as you do when deciding what’s the minimal supported JDK version.
At the moment when you need to upgrade to higher minor version of Scala / JDK you shall release a minor of your library and include information about new requirements.
We already needed to complicate our lives when cross-publishing for Scala 2 minors in the past, let’s not repeat this mistakes in Scala 3.
I’m against special suffixes for LTS / Next version, both series are regular Scala versions.
I.e., do you mean that support of special suffixes in the toolset can be a new problem? I agree, but the proposed policy has nothing about any support from the toolset side.
We de facto have the special status of LTS release.
Cases where library authors will want to support both LTS and Next exist, because of
And people who want to support both regular and LTS releases precisely will invent name schemes for this with suffixes or prefixes … etc. This does not depend on our will. All that we can do is provide conventions to keep such schemas uniform.
On the other side, such cases are relatively rare, so living with the current status quo is possible.
Honestly, I think Javas recent tip and tail model for libraries seems to be a reasonable fit for Scala 3 libraries.
The short summary is essentially: you just use the newest Scala 3 version you need for your library. Users on an older Scala 3 version use an older version of your library. If and when very serious issue (security, no workaround) arise, you release a patch version for the older version of the library.
The JEP argues that this is likely also better for your LTS users, because your library does not change as regularly for them (and being on LTS, they declared a clear intent, that changes are not welcome).
This may require library authors to sometimes fix old versions, but it’s likely that this is less effort overall, compared to any form of cross publishing.