Re: [MirageOS-devel] mirageos 3.0 : let's break some APIs

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

On 05/06/2016 16:47, David Scott wrote:
> One of the things that puts me off making backwards-compatible changes
> today is that I fear I might not be able to complete the whole thing in one
> go and I might leave the world in an inconsistent state which then confuses
> other people and wastes their time. For example if I changed the `V1.NET`
> in mirage/types, and then didn't manage to finish updating and releasing
> everything, and then someone else comes along needing to make an urgent
> change in `mirage-net-xen` to fix a security issue then they might not spot
> the problem initially and waste time trying to fix and release master. IIRC
> when I left big unreleased code changes in ocaml-xenstore people kept
> tripping over them, assuming they had something in common with the current
> code in opam.

isn't this a disjoint problem?  If you want to make security fixes to an
old release, you better create a branch from that release, add the
change and increase the minor version.  It should be clear that "master"
or "trunk" are development, leading to next major releases.  Not
suitable for hotfixes.

> I could make the incompatible change to mirage/types and release that and
> simultaneously add upper-bounds to all the opam packages which depend on
> the old API. However if I'm thorough and add the bounds to old packages,
> inevitably I discover some of them fail `opam lint` checks :/ Inevitably I
> discover some of their dependencies also are missing bounds on other
> packages which have since been released. The more packages I touch the more
> the probability of a travis failure (e.g. timeout) tends towards 1 :( The
> removal of cstruct.syntax took much longer than I initially expected. I
> think this could be fixed with better tooling around opam -- if I could run
> the CI checks (including REVDEPS) entirely locally (e.g. in a container),
> iterate quickly and then supply a transcript of the local CI run in the PR
> to "prove" it's all fine, that would be much easier.

The general discipline of not putting upper bounds onto packages results
in the problem that if you break compatibility you have to manually
adjust all reverse dependencies.  Clearly, automation is possible: build
all reverse dependencies upon a new release and mark which don't work
anymore.

> I quite like the idea of being able to implement 2 versions of an interface
> simultaneously -- it was very convenient that cstruct.1.9.0 supported both
> camlp4 and ppx at the same time.

I don't see how cstruct has two versions of an interface, it had two
syntax extension mechanisms; and in the end we had to add "<
cstruct-2.0.0" constraints to all packages anyways; but true, the 1.9.0
served as a staging release (which we can do with the mirage-dev opam
repository similarly for mirage packages).

> I wonder whether we should split some of the API definitions out from the
> mirage/mirage repo. Instead we could depend on:
> 
> https://github.com/mirage/mirage-block
> https://github.com/mirage/mirage-flow

Sure.  Isn't the actual question what should be in TYPES?  Maybe DEVICE
and FLOW (and maybe TIME) are sufficient?  If you need a clock, you've
to depend on mirage-clock anyways (which can expose a module type
CLOCK).  Cutting each module type into a custom package sounds desirable
at first, but I'd guess it will end up in complex version constraints.


hannes

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel