Currently, there are several aspects to Scala versions that are inconsistent with the SemVer specification, which is the prevalent versioning scheme used by the Scala modules and within the community. In particular, there are two areas I’ve noticed that do not conform to the SemVer spec:
- Scala milestone releases and release candidates do not conform to item 11.4 of the SemVer spec. In particular, if a
<version>-M10 or <version>-RC10 version was released, it would not be ordered correctly according to the SemVer spec. In order to be ordered correctly, it should be <version>-M.X or <version>-RC.X.
- Scala 2 nightly releases are named
<version>-bin-<commit hash prefix> (or <version>-pre-<commit hash prefix> for pre-release versions, which may never happen again). As commit hashes do not provide meaningful ordering, they should not be part of the pre-release portion, which is treated as well-ordered by SemVer. Instead, it should be included as build metadata, something like <version>-bin+<commit hash prefix>.
- I don’t know how Scala 3 nightly releases are named, but they may or may not have the same issue.
I may be the only person bothered by this, or it may be too much of a pain to change, but I just thought I’d put it out there.
This doesn’t really fit into the “Tooling” category, but it doesn’t fit well in any other category either. My justification is that if the version formats were changed, maybe that would affect some tooling?
2 Likes
To be honest I think that semver is more a ritual than something really useful.
Whatever we do any versioning approach is just a convention. Unless we use content hashes for versioning (or “binding”/“linking”).
I won’t mind any versioning scheme while it works.
2 Likes
At least swapping milestones and RCs over to semver would be good I think. It seems like an easy quick win for much tooling.
Nightlies I’m not so sure: from my understanding of semver, the part after the + is not supposed to be meaningful in differentiating versions, just as metadata. That the current scheme is not well-ordered semver is maybe better than that all nightlies are the same version according to semver.
4 Likes
What would the advantage be of having a semver compatible ordering between RC, M, and nightly releases?
I wasn’t sure, so I’ve had to look it up:
Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence.
I believe what that means is that the two versions still differ, but neither is a “higher” version.
Regardless, I don’t feel super strongly about nightlies being unordered wrt each other vs being effectively randomly ordered wrt each other. There’s no practical way to meaningfully order them regardless.
The advantage would be that libraries and tooling can use existing SemVer functionality to parse and compare versions, without having to write custom functionality for Scala pre-releases. This can be very useful for determining when a new version is available without having to write custom handling.
4 Likes
I just realised that Scala 2 nightlies currently sort higher than M and RC pre-releases, due to the fact that SemVer uses ASCII order for precedence, and nightlies start their pre-release segment with lowercase letters. I think it would also be preferable to have nightlies sort lower than official pre-releases. the easy way to do that for binary compatible ones is to replace bin with BIN. For non-binary compatible ones that use pre (which might not ever exist again anyway), something else would need to be used. Perhaps ALPHA or just A.pre.
If someone who knows what Scala 3 nightly versions look like wants to chime in about those, please feel free.
3 Likes