Padraig O'Briain writes:
> I said Volatile as that is what our RE recommended to me.
>
> Having read the Interface Taxonomy it looks to me that Volatile is the
> normal classification for free or open source software (FOSS) which is
> what this is.
Not really wanting to belabor this, but ...
There is *NO* direct translation from origin of software into
stability level. None. Please delete the notion that FOSS ==
Volatile, because it's simply not true and it leads to bad decisions.
Instead, the stability level is the stability that we are offering the
users of that component. We're promising that it won't change in
incompatible ways or without notice unless a certain kind of release
is made.
There are many ways to evaluate and deal with this, and thus the lack
of any tie to "is/is not FOSS." For instance, you may determine:
1. You want to upgrade as often as possible without even really
thinking about it much; just download source, compile, and go.
2. The upstream source has a poor history of offering compatibility
and tends to change things often and break users.
3. You don't really care if users of your component get broken,
because getting "newer" bits is more valuable, and perhaps
nobody really depends on it anyway.
In that case, "Volatile" makes sense. It allows you to introduce
incompatibilities even in patches when necessary.
Or you may determine:
1. You want to upgrade often.
2. The upstream source has a decent history of offering
compatibility or at least properly marking source changes that
are incompatible ("flag days").
3. You don't want to break users if you can avoid it, at least
within a Minor release of Solaris.
4. If the upstream does break something anyway, you'll do something
to fix it, meaning one or more of:
a. Refuse to take that source change; stick with the old
version until the next Minor release.
b. Contribute fixes upstream to restore compatibility.
c. Offer multiple concurrent versions (where feasible).
d. If you can't get the changes upstream and must upgrade the
bits, then fork the source, and apply local patches to
restore compatibility.
In that case, "Uncommitted" is probably better. It gives a greater
promise to users, and thus allows them more secure use of the software
and a better chance of building on it.
Similarly, "Committed" can be used for FOSS. It just means that we're
promising to break things in the bits that _WE_ deliver only when
there's a Major release. Many FOSS projects are well known to be
stable enough to promise exactly this level of support.
In many ways, "Volatile" is just the worst possible choice for any
component. It means that nobody can build on it, because they're
building on quicksand.
Of course, you can always upgrade the stability later, but few ever
bother revisiting the choice, so it's worth putting at least a little
thought into it. Simply equating FOSS to Volatile, though, doesn't
that.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
