[Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris]

[James Carlson]

Roy Lyseng writes:
> The dilemma of dealing with open-source software is that it would be 
> very hard to get a community to sign a contract that they commit 
> interfaces until the next release of their software. Besides, we are 
> releasing Solaris independent of memcached releases, which might prove 
> to be an even bigger problem.

It's not really that much of a dilemma.  We don't ask Sun employees to
sign any contract, either.

The stabilities reflect a number of different issues, all of which
need to be taken into account:

  - the needs of the consumers (there's no use in producing interfaces
    that the consumers cannot use)

  - the *likelihood* of incompatible changes

  - the ability to detect and adapt to changes

  - the way in which changes are documented for users

  - how the changes will arrive (bits don't appear in the WOS by
    magic)

It's not just a simple equation where "not paid by SMI" is ever
equivalent to "we have no control and no idea when it might change, so
it's Volatile."  That's exactly the falsehood that sank the usefulness
of "External" in the previous interface taxonomy and I'd like to see
the same pitfall avoided for "Volatile" -- or we're just going to have
to remove that attribute from the taxonomy.

> So I guess that our strategy can be to declare interfaces as Uncommitted and
> 1) expect the community to provide compatible interface changes only, or
> 2) (if 1) does not hold) be prepared to support an older compatible 
> version of memcached until the next minor version of Solaris (5.12).

Yes; that's entirely viable.

Depending on the technical details of a specific change, many other
responses are also possible.  Some incompatible changes are not
unwelcome.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677