Ah, yes, I suppose 1.0 brings with it expectations of policy changes
I am fairly tempted just to continue with current policies. Things
like binary stability don't seem to be easy to achieve. And I'm not
sure that other practices of mature systems, such as Linux' stable
branch vs. development branch, solve important problems for SBCL.
But it is a particularly reasonable time to review policies and perhaps
On Fri, Aug 18, 2006 at 10:10:30AM +0100, Christophe Rhodes wrote:
> Juho Snellman <jsnell@...> writes:
> > * 1.0.1 released one month later, no guarantees over source / binary
> > compatibility with 1.0. But we encourage people releasing
> > non-portable internals-using software to maintain
> > backwards-compability with 1.0 at least until the release of 1.1,
> > expected to happen about a year later.
> This sounds plausible. (In some sense, it's the same-old aggressive
> philosophy as the 0.9.x development: if you're using internals, it's
> your responsibility to maintain as much backwards-compatibility as you
> want.) It's more work for those writing and maintaining libraries
> which need internals, which is in some sense where the work needs to
> be placed; on the other hand, as someone who helps support some of
> those libraries, even I weary somewhat of the compatibility treadmill,
> so I'll just say that post-1.0 it would be nice to think about
> providing nice exported interfaces for some of the internals.
Both Juho's idea and Christophe's idea sound plausible to me.
I don't know what's the best way to help the library maintainers with
compatibility issues. The ideal of settling nice exported interfaces
seems seldom to be realized in practice, and of course constant
fiddling is frustrating.
I've largely given up on the idea of maintaining .fasl binary
compatibility any more than we do already. I could perhaps be
convinced it's worth it after all, but right now it seems like too
much of a maintenance burden. It's not so easy to test, either, since
a fair fraction of things which can fail are obscure.
A minimal-patches-for-bad-bugs-only branch running from a particular
version --- traditionally relatively-round-numbered- releases like
1.0, 1.1, etc. --- can be useful. However, it might call for a
different kind of motivation than most of our developers have. Mostly
people choose to work on software that scratches their own itch, and
my guess is that few current SBCL developers have systems which would
benefit much from such a branch. That doesn't mean that there's no
need for it, but if there is little overlap between current developers
and people who need it and/or have the energy to work on it, it might
be an odd fit to the current administrative structure. Possibly it might
even be maintained in a separate repository with separate permissions,
committers, and/or administrator.
> The other side of this coin is worth examining too, though it's
> somewhat harder to get hard data. In the past, there have been
> anecdotal reports of people who have rejected SBCL for their use
> because of (a) immmaturity and/or (b) instability. Some of them might
> even be reading this list, but if they're not, maybe readers know
> someone in that situation. It might be interesting to know if the
> kind of post-1.0 development policy that Juho proposes would work for
> those people, and if not, why not.
Indeed, people interested in this should probably speak up. If you're
reading sbcl-devel you're probably already qualified to have an
opinion:-) and if you have much experience using SBCL or other
software in a way which depends on this kind of policy, you're
probably more qualified than me...
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C
Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph