[RFC] Deprecating opam 1.2.0

Community
1

This is all for remaining users of OPAM 1.2.0, to see if it can be actively deprecated in favour of OPAM 1.2.2 and higher.

Why deprecate opam 1.2.0

OPAM 1.2.0 was released in October 2014, and saw rapid uptake from the community. We did some rapid bugfixing to solve common problems, and OPAM 1.2.2 was released in April 2015. Since then, 1.2.2 has been a very solid release and has been the stable version in use to date.

Unfortunately, part of the bugfixes in the 1.2.2 series resulted in an opam file format that is not fully backwards compatible with the 1.2.0 syntax, and the net effect is that users of 1.2.0 now see a broken package repository. Our CI tests for new packages regularly fail on 1.2.0, even if they succeed on 1.2.2 and higher.

As we prepare the plan for 1.2.2 -> 2.0 migration, it is clear that we need a “one-in one-out” policy on releases in order to preserve the overall health of the package repository – maintaining three separate releases and formats of the repository is not practical. Therefore the 1.2.0 release needs to be actively deprecated, and we could use some help from the community to make this happen.

Who is still using opam 1.2.0?

I found that the Debian Jessie (stable) release includes 1.2.0, and this is probably the last major distribution including it. The Debian Stretch is due to become the stable release on the 17th June 2017, and so at that point there will hopefully be no distributions actively sending opam 1.2.0 out.

Is there anyone else that is still packaging 1.2.0? Please comment here if so, and we should move them away.

How do we deprecate it?

Due to the format changes happening in a minor version, it’s a bit difficult to give opam 1.2.0 users a smooth transition experience, to my knowledge (@AltGr may correct me here). I would propose:

  • putting a notice on opam.ocaml.org that 1.2.2 is the only supported stable release.
  • can we somehow put in a request to debian-stable to add a post-installation message that the upstream package will no longer work since the repository?

If there are any users of opam 1.2.0, particularly industrial ones, please do speak up now. By performing an active deprecation of an older release, I hope we can focus our efforts on ensuring the opam users have a good out-of-the-box experience with opam 1.2.2 and the forthcoming opam 2.0 :slight_smile:

1 Like
2

I’ve had a few private enquiries about how people can help, and one useful thing to do would be to refresh this: https://github.com/avsm/debian-jessie-backports-opam

It is a Dockerfile that used to build opam 1.2.2 as a backport on top of Debian Jessie. If that could be updated and made so that it doesnt break on minor package updates upstream, we can publish it as a signed remote for older users of stable. I don’t have time to do this myself at the moment unfortunately, so contributions are most welcome.

3

I have now opened up a PR against opam-repository to stop testing 1.2.0, since it breaks so often anyway. https://github.com/ocaml/opam-repository/pull/9477

4

The 1.2.0 repository has been frozen on the state pointed to by the 1.2.0 tag, with proper redirections in place.
And the deprecation is announced on the platform blog.

So the way is now free :slight_smile:
there are already a few git+https errors on the state chosen for 1.2.0 though.

1 Like
5

Thanks @AltGr! It’s a pity to leave 1.2.0 permanently frozen in a slightly broken state, but if anyone in the community cares to find a revision that works, we can revert it to that. We will do a more structured deprecation of 1.2.2 to ensure that it remains in a functional state for more years!

6

Out of curiosity Is there a message that tells the users of 1.2.0 that they are using a deprecated opam-repo when they opam update ?

7

No, we should have added a repository “motd” for that. They’ll only see that they have been redirected.

1 Like
8

The alternative would be to put no mirror or redirection, and use an opam-version: "1.2.2" field, which would yield:

[ERROR] The current version of OPAM cannot read the repository "default". 
        You should upgrade to at least version 1.2.2.

interestingly, that locks out of opam init, but opam update, while printing the warning, still seems to proceed (or attempt to).
It is possible to add an announce: field, for the future, without breaking compatibility with older opam releases (if opam-version is newer, opam 1.2.2 silently ignores fields it doesn’t know about, but can still handle redirect: as long as it didn’t change format)

9

I think it’s a sensible thing to do. If there’s a clear message that you are using deprecated stuff we may end up with less people coming out of the blue with opam install problems for which we’ll need a few exchanges before understanding that they are using the deprecated stuff.

1 Like
10

@hannesm points out on this cstruct issue that the Whonix 13 distribution still packages opam 1.2.0.

Would anyone have any contacts there to help move it forward to a more modern package? Any help appreciated!

11

FWIW, Whonix is based on Debian stable (see )https://www.whonix.org/wiki/Install_Software#Prefer_Packages_from_Debian_Stable_Repository, and they have “jessie backports” - but jessie still has opam.1.2.0 (see https://packages.debian.org/jessie/opam) – the “fix” thus would be AFAICT to get opam.1.2.0 into debian jessie – but I don’t know whom to ask (likely some debian developer) and what the exact process is.

12

I guess they need to move to the latest Debian Stable release, which has 1.2.2…

13

Related Debian bugreport.