[opam-devel] Preparing the path for 1.2
anil at recoil.org
Fri Sep 19 16:09:34 BST 2014
One thing that worries me is that some people did not see the repo redirection for OPAM 1.1, and this might happen again for 1.2 until we figure out why (I think it might be just that they did a Git init instead of the default).
Would it make sense to activate the repo redirect to the new branch ahead of the release? The only way we will know if people have moved over is via the HTTP remote (since the Git remote is hosted on GitHub without direct logs). Which leads on to my next question -- will there be a separate HTTP URL space for 1.1 and 1.2 for the HTTP remote?
On 19 Sep 2014, at 16:02, Louis Gesbert <louis.gesbert at ocamlpro.com> wrote:
> Hi all,
> As you may know, the 1.2.0 RC2 has just been tagged . However, as discussed at , planning the migration of the repository is quite a delicate matter ; this doesn't have to be done at the same time as the release itself, but some confusion may arise if we advertise a new workflow that leads to packages that get refused from the main repo because they're not 1.1 compatible.
> We tried to improve compatibility for the next release, but for 1.2 there are just too many changes and opam 1.1 _won't_ nicely handle them. So here is how I have been preparing:
> - a batch conversion of the existing repo : not required but useful for 1.2 (adding dev repos for archives held on github, setting ocamlfind deps as build-only, turning depopts constraints to conflicts ...). This is useful as a starting point for repo extension and example, and done using scripts in `admin-scripts/` 
> - a `admin-scripts/to_1_1.ml` script in opam  that can convert a package back to 1.1 format. I successfully tested it on the above repo and with opam 1.1 ; there may be corner cases on new 1.2 opam files that this didn't get into, but these can be caught by Travis before they break.
> - updated admin scripts on the 11-bridge branch of opam.ocaml.org . The new scripts create a duplicate of the repo at opam.ocaml.org/1.1/, branch version-triggered redirects between the two, and apply the above script to the 1.1 repo mirror at every update. This should make it transparent whichever opam version is used.
> - tested the opam.ocaml.org scripts on a local mirror I set up, and they seem to work fine (after _a lot_ of tweaking) ; note that these can be pushed live beforehand, they'll set up the redirects but the translation script doesn't change opam files with `opam-version` < "1.2" so it won't cause any user-visible changes until we actually accept 1.2 opam files in the repo (except for the "permanently redirected" message)
> What remains to do:
> - setup the opam-repository travis scripts to apply the 1.1 rewrite before testing, for opam versions < 1.2. Only tricky part is to get hold of a recent enough opam-lib to run the script (maybe we could cheat and put a standalone bytecode exe on opam-repository for that ; well one for 4.01 and one for 4.02 since the format changed...). This way PRs to opam-repo containing 1.2 opam files will be correctly tested, as well as the rewrite.
> - release !
> Finally, note that I'll be moving across the globe next week, and won't be available for two weeks or so. Everything should be ready to release as soon as I get back.
>  https://github.com/ocaml/opam/releases/tag/1.2.0-rc2
>  https://github.com/ocaml/opam/issues/1662
>  https://github.com/ocaml/opam/pull/1325
>  https://github.com/ocaml/opam/tree/master/admin-scripts
>  https://github.com/ocaml/opam/pull/1743
>  https://github.com/ocaml/opam.ocaml.org/tree/11-bridge
>  https://github.com/ocaml/opam-repository/tree/1.2-test
> PS: during the course of these tests, I sadly found out that repo redirect handling in 1.1 wasn't that good: it works at update but not straight-away at init. See comment at https://github.com/ocaml/opam/pull/1744
> opam-devel mailing list
> opam-devel at lists.ocaml.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the opam-devel