Re: [Caml-list] OCaml 4.04.0+beta1

[Louis Gesbert <louis.gesbert@ocamlpro.com>]

I confirm what has been said before: opam follows the Debian convention of having `1.0~foo` < `1.0` < `1.0+foo` ; and you would generally write the constraint as `< 4.04` to exclude `4.04.0~beta` from the range, although for finer constraints you can need a suffix `~`, e.g. `< 4.04.1~` to avoid including `4.04.1~beta`. But constraints shouldn't depend on patch versions right ?

On the other hand, constraints such as `>= 4.04.0` don't include betas if named `4.04.0~beta`, while it would include `4.04.0+beta`

--

For the curious about handling compiler versions in opam 2.0, here follows a glimpse on how that will be done. For the not-that-curious, let it just be said that beta versions (`x.xx.x+beta`) are handled just like other "variants" (e.g. `x.xx.x+fp`) and as such won't get picked up by default, so this won't really be a problem for now.

OCaml implementations are split into three different, mutually conflicting packages:

- Stable OCaml release are packaged as `ocaml-base-compiler.version`
- Any other OCaml version (with a `+foo` suffix) is packaged as `ocaml-variants.version+foo`
- The system compiler, if installed, is available through a dummy package called `ocaml-system.version`

Then there is a wrapper package that is named `ocaml` proper, and that has the corresponding OCaml base version (i.e. `4.03.0` for all packages with versions `4.03.0+foo`); this is the one all normal packages are expected to depend on, so that they don't need to consider every variant. In addition, this package polls the compiler installation to define a few variables such as `ocaml:native-dynlink`.

This scheme allows to have the package work with `4.03.0+flambda` with a dependency to `ocaml = 4.03.0` rather than needing`>= 4.03.0 & < 4.03.1~` ; but it also means that any beta or +prXX version will be treated as the main version (as was the case with the `available:` field and `ocaml-version` variable). Note that the ordering of versions of `ocaml-variants` is mostly irrelevant; but the beta could indeed get packaged as `ocaml-base-compiler.version~beta` if we want to give it the same level of advertisement as compiler releases.

The rewrite is already available and a mirror is present at https://opam.ocaml.org/2.0 , to which the "master" version of opam gets automatically redirected.

Note that this scheme could be simplified once we handle a `provides:` field. But since this brings a whole lot of complications of its own, one thing at a time.

An alpha of opam 2.0 featuring all this, and much more, will be announced shortly for anyone keen on helping to test it :)

Best,
Louis -- OCamlPro


> - David Allsopp, 16/08/2016 12:54 -
> Damien Doligez wrote:
> > > On 2016-08-12, at 14:50, David Allsopp <dra-news@metastack.com> wrote:
> > >
> > > If such a change were agreed, it would also be possible to alter opam
> > lint (or at least opam-repository linting, once that's fully a "thing") to
> > display a lint warning/info that things like ocaml {< "4.05"} probably
> > mean "ocaml" {< "4.05~~"}.
> > 
> > So every mention of an OCaml version number in every opam package
> > description file will have to be suffixed with a ~. And that has to be
> > done before we change the OCaml numbering scheme.
> 
> Yes, but as far as OPAM packages are concerned, it sounds as though that's what we "should" already be doing. It's also something that can be done mechanically (cf. the removal of ocamlbuild in 4.03.0).
> 
> > And I still don't know what's the upside, except for "that's how Debian
> > does it"...
> 
> It would mean that OPAM would be automatically clear that the release version (4.05.0) is superior to the release candidate (4.05.0~rc1) - that's philosophically nice, if nothing else. That said, I don't think there's any technical reason why the OPAM package version has to match the OCaml version exactly; it'd just be mildly confusing.
> 
> 
> David
> 
>