On Fri, Feb 01, 2008 at 04:13:00PM -0500, James Carlson wrote:
> Nicolas Williams writes:
> > Brian was right though: Volatile is "public and unstable for folks
> > outside the WOS" and "consolidation private for better-than-volatile
> > consumers in the WOS" (my rough translation of what the taxonomy says).
> > I still think it's better to go with Uncommitted, but I'll live.
>
> True, but if they're doing this because they're worried about making
> fixes for other consumers inside the WOS, what chance does any of
> those customers, enticed by the presence of this well-known but
> Volatile interface, have?
Also, if it really is a shared component, then I think we could say that
responsibility for updating it will be that of any team that needs an
update. I don't see the JDS team as any more or less equal than any
other internal SQLite consumer. If our support model is that "the team
that integrated owns it" then I'm afraid that will likely not work well
over time (among other things, teams come and go, re-orgs happen).
> My understanding of the taxonomy is that it's primarily there to allow
> us to tell people how interfaces might change over time, and thus the
> risks in using them, and not that we're concerned about or just unable
> to support them when used.
Right. When it comes to software of external provenance we don't always
have the ability to make good judgements about interface stability.
Here we have that ability. If we didn't could still go with Uncommitted
provided we understood there was a high likelihood that we could end up
shipping multiple versions.
> Equating a higher (or a lower) stability level with a generic promise
> of support seems like an error to me.
I agree. This is why I think going with Uncommitted would help: it puts
a small burden on any team that would update SQLite, to decide whether
to (ship multiple versions || wait for more approrpiate release || fix
any incompatibilities).
Since shipping multiple versions is not resource-intensive, and since
the likelihood of backwards incompatible changes here is so low, I think
the best approach is Uncommitted.
If it would help, I volunteer to draw up a list {API, stability
attributes} based on the SQLite documentation.
Nico
--
