[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] V1 vs V2 mirage-types
>> slowly following up - I still do not understand why we would want to >> have two interface versions here -- shouldn't versioning be kept at >> the package level rather than the interface level. > > I don't know (yet) the specifics of mirage but having thought about that in > another context (assemblage) I also think that module signatures for API > versioning seems to be a rather bad idea and could be a source of subtle bugs > in the future. Not to mention that once you will have the relief of having > solved the versioning problem at the package level it will only be so soon > that you have to deal with it again in your code. It's certainly true that the V1/V2 stuff is confusing and hard to explain to new users (and to ourselves, which is a bad sign). It sounded like a good idea at the beginning, and we did that to mirror the xen-api versions bumps, but it our current use of API versioning doesn't really seem to help to actually manage different API versions. One way to fix that is indeed to remove all V1/V2 stuff, and propagate version constraints of opam packages in the mirage tools. Every major version of mirage could then define the set of implementations which satisfy the current mirage-type interface. Thomas _______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |