Add ocaml-src.4.13.0

[kit-ty-kate]

Mirage packages always get left behind because of the lack of ocaml-src package in opam-repository.
This proposal creates a placeholder package to update at each alpha/beta/rc (with their respective checksums) and one last time for the final release.

@Octachron @hannesm @mato what do you think?

[camelus]

Commit: 7919c82

Good to see you Madam.

🌤️ opam-lint warnings 7919c82

• ocaml-src.4.13+trunk has some warnings:

  • warning 36: Missing field 'bug-reports'
  • warning 37: Missing field 'dev-repo'

---

☀️ Installability check (+1)

• new installable packages (1): ocaml-src.4.13+trunk

---

🌤️ 1 ignored non-opam files:

• packages/ocaml-src/ocaml-src.4.13+trunk/files/META

[hannesm]

I am in favor of this PR.

[avsm]

I'm generally fine with opam-repository tracking ocaml trunk with git urls, so that our metadata is consistent.

[avsm]

This should be a git src so that opam update will pick up on upstream commits and track them correctly.

[kit-ty-kate]

if we do that, we need to do the same thing in ocaml-variants.4.13.0+trunk as it is not currently the case

[avsm]

Those are compiler packages, whereas this is a library package (that is, used as a dependency in various Mirage builds).

[avsm]

(note that it's fine to change the compiler packages too, but that's a separate change unrelated to this one)

[dra27]

I don't know what @Octachron's opinion is, but I'm slightly uncomfortable with version 4.13.0 of the OCaml sources appearing to be published! Can it be a simple matter of it being 4.13+trunk (no need for the .0)?

[avsm]

Yes good idea, adding +trunk to the version would reflect the development status nicely.

[mato]

Looks reasonable to me. As others have said, having the version be 4.13+trunk is a good idea. It does mean that there will need to be a manual update to ocaml-src and Mirage ocaml-freestanding once a 4.13.0 is released, but that won't hold back Mirage packages in the mean time.

What is the purpose of the META file?

[hannesm]

What is the purpose of the META file?

IIRC it is needed for ocamlfind to consider the package being installed, from ocaml-freestanding Makefile: cp -r `ocamlfind query ocaml-src` ./ocaml.

[kit-ty-kate]

I don't know what @Octachron's opinion is, but I'm slightly uncomfortable with version 4.13.0 of the OCaml sources appearing to be published! Can it be a simple matter of it being 4.13+trunk (no need for the .0)?

I agree with 4.13+trunk, however one annoying thing with naming it like this is that 4.13+trunk < 4.13.0 according to opam/debian version ordering. The version ordering is sort of true now but it won't be true anymore after the release. 4.13.trunk would do the job in that regard. What do you think? If this scheme is fine, we might want to switch ocaml-variants.4.13.0+trunk to use the same version scheme (ocaml-variants.4.13.trunk) as it avoids the deletion/moving of for instance 4.12.0+trunk --> 4.12.1+trunk that was a bit annoying in CI after the last release.

[dra27]

I don't know what @Octachron's opinion is, but I'm slightly uncomfortable with version 4.13.0 of the OCaml sources appearing to be published! Can it be a simple matter of it being 4.13+trunk (no need for the .0)?

I agree with 4.13+trunk, however one annoying thing with naming it like this is that 4.13+trunk < 4.13.0 according to opam/debian version ordering. The version ordering is sort of true now but it won't be true anymore after the release. 4.13.trunk would do the job in that regard. What do you think? If this scheme is fine, we might want to switch ocaml-variants.4.13.0+trunk to use the same version scheme (ocaml-variants.4.13.trunk) as it avoids the deletion/moving of for instance 4.12.0+trunk --> 4.12.1+trunk that was a bit annoying in CI after the last release.

Ah, thanks for looking at this properly - I had a memory there was a reason we didn't always drop the ".0", and this is it! Two thoughts:

• Once OCaml 4.13 is released, we wouldn't want the temporary package to be used, so in many respects ocaml-src.4.13+trunk < ocaml-src.4.13.0 is a feature. Perhaps we should there better choose a better moniker than +trunk - +pre or +prerelease?
• For ocaml-variants, I had been thinking of another rename to avoid the version bumps too - given that trunk is the only the name of the main branch (and the OCaml dev team are considering a rename at some point), switching to the .trunk suggestion works, but again with a different moniker - perhaps ocaml-variants.4.13.next or .dev? (that can move to another issue, though).