[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.