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

[Anil Madhavapeddy]

On 1 Feb 2014, at 11:48, Roberto Di Cosmo <roberto at dicosmo.org> wrote:

> On Fri, Jan 31, 2014 at 07:54:20PM +0000, Anil Madhavapeddy wrote:
>> On 31 Jan 2014, at 17:28, Roberto Di Cosmo <roberto at dicosmo.org> wrote:
>> 
>>>    I am a bit unhappy with the current state of affairs, where new
>>>    versions of opam appear with incompatible changes in the repository format,
>>>    hence different versions of the repositories: people using old versions
>>>    of opam get lost in a limbo-like repository with non updated packages
>>>    until they realise they need to recompile a new version of opam
>>>    to see the light again.
>> 
>> To be clear, the reason for OPAM 1.0 to 1.1 being incompatible was "unplanned".  The original release was too strict with it's parsing, and OPAM 1.1 is now far more lax.
>> 
> 
> Sure Anil, nobody is implying here that this was deliberately planned :-)
> Simply, this kind of things just happen, and especially so when a piece
> of software is under heavy development.
> 
> That's why one needs a clear, and simple, mechanism to ensure a smooth
> transition when incompatibilities arrive (and there will be more, and
> unexpected ones, you can bet on it). 
> 
> The one I outlined has no pretense of originality, it's just good practice.

My point (perhaps not made clearly enough) is that we already followed your
practice with OPAM 1.0 -> 1.1.  The `repo` file performs the redirection to
the new repository (from http://opam.ocamlpro.com containing the OPAM 1.0
format repository, to the new one at https://opam.ocaml.org containing the
1.1 format).  Since only OPAM 1.1 looked for the `repo` file, older clients
would continue to work fine, albeit with outdated packages.

Was there some specific change you were proposing for future upgrades of
OPAM?  It's important to know those now, since some of the logic has to be
baked into the current 1.1 client in a point release.

-anil