[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] V1 vs V2 mirage-types

On 17 Nov 2014, at 14:43, Thomas Leonard <talex5@xxxxxxxxx> wrote:
> On 13 November 2014 17:30, david <unitedbiscuits@xxxxxxxxx> wrote:
>> On Wed, Nov 12, 2014 at 11:24 PM, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>> For example, the Fat module implements the V1 FS interface. Maybe it
>>> will never be updated to the V2 FS interface, but I might still want
>>> to use FAT in my programs, alongside other, newer, filesystems.
>> Wouldn't that suggest that Fat was unmaintained and should be either
>> dropped or ported?
> In an ideal world, perhaps. But even if so, consider this scenario:
> I have a unikernel using V1 FS and V1 NETWORK. Mirage 2 is now stable,
> and I want to migrate to the V2 APIs. Of course, I prefer small
> incremental changes, so I'd like to upgrade the FS code to V2 this
> week and test it, then upgrade the net code next week.
> Making it hard to run with a mix of versions makes upgrading harder
> (or impossible, if one library isn't maintained), and that in turn may
> cause people to stick with the old versions (cf Python 3).
> I don't think it's a problem in the case of Mirage 1 -> 2 because
> there's so little existing software, but in general it may be.

Perhaps we should think in terms of STABLE and DEVEL, instead of V1
and V2 (which imply a V3, V4, etc).  If we just have two interfaces,
then the class of breakages are well understood:

- A change in a STABLE interface requires an immediate rev to all the
  packages that use the old interface, or else they'll simply be
  Mirage incompatible.  Old implementations will be consigned to the
  depths of constraint hell so they will not be selected with the
  latest Mirage version.

- DEVEL packages represent work in progress interfaces, and libraries
  should do their best to keep up with the interface.  When we're happy
  that a certain interface is behaving well, it can be promoted to


MirageOS-devel mailing list



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