[opam-devel] How to manage a package manager (Was: Re: [opam] Build clarification (#1149))

[Anil Madhavapeddy]

On 3 Feb 2014, at 10:54, Thomas Gazagnaire <thomas at gazagnaire.org> wrote:

>> @samoth : even an approximate brain dump would be very useful here...
>> I have opened an issue for this purpose https://github.com/ocaml/opam/issues/1150
> 
> Regarding the upgrade issues discussed there.
> 
> - you can info OPAM clients which minimal version is needed for a given repo (add `opam-version: "1.1.1"` in `opam-repository/repo` . This information will be read by OPAM 1.0 but it will do nothing useful, behaviour which has been fixed by OPAM 1.1.0 to show a nice error message. 
> 
> - as we though this was not enough flexible, we instead rely on an other mechanism to ensure forward compatibility: the individual opam files contains an (optional) `opam-version` field which is the minimal version of the client needed to read them. From OPAM 1.1.0, the client starts to skip these instead of failing (as it was the case in 1.0.0). Also, OPAM 1.1.0 will skip the fields it doesn't know about (you can still tell it to fail on error using --strict).
> 
> - to help upgrading, we also added a `redirect` field in `opam-repository/repo`, which can be enabled depending on the version of the OPAM client reading it. This will let us having different repo for different versions. The goal was to keep the most up-to-date description compatible with the latest version, and back port automatically new additions to previous repository versions. There is a `--compat-mode-1.0` command-line option which starts to do that, but this is clearly not the most urgent need so this didn't go very far (and won't go very far, unless someone proposes a patch).
> 
> - the latest version of OPAM is always available at the same url: https://github.com/ocaml/opam/archive/latest.tar.gz
> 

There's one missing bit of machinery in all this -- how to notify an old client that a new client is available.  The options above allow us to reject a client, but not to notify the client that an upgrade is possible.

Hence my suggestion to add a 'latest-client: <url>' field.  This URL could be cached by the client and the contents displayed when it changes (e.g. a changelog).  David Sheets pointed out that we need to consider what to do if multiple remotes have different URLs, for instance.  

Incidentally, I just got a mail from Jacques Garrigue complaining that he couldn't build ocaml.org, and it was because (please, noone laugh) his version of OPAM was still 1.0.  The problem here is that there is no error message in this case -- the user is simply stuck with older package revisions.

Should we declare OPAM 1.0 "end of life" at some point soon, and push something to the OCamlPro/opam-repository repo to reflect this (perhaps delete all the packages and add one saying "upgrade_to_opam_1_1")?  Louis, perhaps we could check the ocamlpro apache logs to determine how many people are still hitting that server?

-anil