Multiple parallel releases (2) of a package with opam

I’m in the process of preparing a major upgrade of camlp5, as well as a significant package (of PPX rewriters) based on camlp5. I’d like to release these, but want to preserve the current camlp5 release-train, so that if there are bugs, they can be fixed there. The current camlp5 release is 7.12, so I thought I’d number the new camlp5 version something like 7.99.01 (or maybe 8.00-alpha01 ?) Is this something opam supports? That is, releasing a version 7.13 (if bugs arise in the current release) as well as a version 8.00-alpha02 (for example) simultaneously?

The 8.00 release will have a ton of new function, and some old things will break, so it’s worth doing it in small steps. I realize almost nobody uses camlp5, but minimizing disruption is important for even those few users.

You can release multiple versions of packages just fine, but opam will always prefer the freshest version. Thus, they will select the 8.0.0-alpha02 unless it is otherwise constrained. However, users having problems with it can always fall back to the specific version in their own opam file.

We do prefer you do not release alpha versions into the stable opam repository though. If it’s not ready for general availability, users can opam pin to get a version that needs more testing.

One other issue is that 8.0.0-alpha1 will be chosen instead of 8.0.0 (once it is released). To avoid that, you should version the package as 8.0.0~alpha1. We tend to keep an eye on this when reviewing, but it’s subtle and slipped a few times

1 Like

Is there a typo in your reply? Just want to check. Also, are the rules for version-numbers and their ordering documented somewhere? If not, no worries, now that I know there’s something interesting there, I can look in the source for the deets.

The tilde ~ is from Debian version policy: .

Oh ha, thank you for clarifying! My eyes are going! Tilde! Tilde! Not minus! Tilde!

It’s not so much for the testing, that I feel like it should be released as an “alpha”: it’s for the lack of documentation. The code will be well-tested, but poorly documented, b/c … been spending all the time on the code (and copious testing for sure). I figure it’s time to get a release out, but I don’t want people looking at it to think that the lack of documentation is anything other than transitory.