Context: atdj is an opam package, which used to have its own version IDs like 20151001.01.2. It now follows the same version IDs as the rest of the atd suite, and the latest version is 1.13.0. Naturally, 20151001.01.2 being greater than 1.13.0, the latest version according to opam is not the latest version of the software.
What’s the best course of action here?
We could simply remove the old versions from opam-repository. Assuming no user depends on these old versions, is it fine to just delete them from opam-repository?
Is there a worry-free solution that would let us somehow mark specific package versions as “won’t be installed unless explicitly requested” (or “deprecated”)?
One worry-free solution would be to create a new opam package, using the new revision scheme.
For example, newatdj.
I am worried that the opam-repository is not an append only store.
It means that the reproducibility of installing old software is bad.
The other possibility is to use a version number which is considered higher than previous versions (it is a bit sad OPAM does not support a Debian-like epoch counter in versions).
For an example you can see is Core which went from 113.33.03 to a version named v0.9.0.
The easiest way to do this is pick a higher version. For Core, we prefixed the release with v, so you could just name your new version v1.13.0 and it’ll be higher than the 20151001.01.2 version without any new features being needed in opam.
While this works from a technical perspective, from a package user point of view it’s not a great solution.
Most of the packages in the opam repository simply use X.Y.Z for versions. The “solution” you propose puts the burden of the fact that the versioning scheme changed on the package users, which have to remember each time they use that particular package that its version needs a v prefix to be specified correctly.
I don’t know about nor investigated exactly what @perry proposes, but if that can solve the problem without resorting to such versioning naming hacks that would be great.
In short, the suggestion made by @perry is to let the packager associate an integer of their choosing with each version of the package. This defines a total order over versions independently from the syntax of the version string. I like this proposal.
The notion is straightforward. “Epoch” is effectively a (usually hidden to the user) most significant numeric field for a version number.
The internally used version for newer/older comparison purposes becomes epoch.maintainerversion. So, for most packages, given that the epoch is 0, the version is effectively 0.maintainerversion. If the maintainers change their numbering scheme, the epoch gets bumped to 1, so the new 1.maintainterversion is always higher than 0.maintainerversion, even if the new maintainerversion is numerically smaller than the old. If the maintainer again changes their versioning scheme, the epoch is again incremented by 1.
The epoch would probably be set by having an epoch: field in the opam file that defaults to 0, so existing opam files would not need to be touched (and in fact, for new packages, there would be no need to add an epoch: field either since the default is already correct.) If the upstream version scheme changes, however, epoch: 1 may be set, and the epoch can be bumped later if upstream changes yet again.
The epoch is not shown to the user by default, so the user sees only the “normal” version corresponding with the upstream versioning scheme in current use and can see that the package corresponds with some particular release.
BTW, this is not my notion — this mechanism is used by many existing packaging schemes. It’s very effective.
It’s a bit more complicated in opam since the version can currently be independently inferred from the package metadata (from the directory name). Thus there could be odd interactions if (for example) a package is pinned and the new version has an epoch. This can all be solved with some thought as to the various permutations.
@dbuenzli my suggestion was for existing releases of opam to solve @mjambon’s immediate problem. All the other solutions require a future release of an opam client, and some backwards compatibility that doesn’t exist yet.