about the upcoming 0.8.20 release: should be today
about upcoming 0.9 and 1.0:
On Thu, Feb 24, 2005 at 10:07:23PM +0000, Christophe Rhodes wrote:
> Nikodemus Siivola <tsiivola@...> writes:
> > The only question in mind is whether 0.9 aims to be the direct
> > predecessor of 1.0, or just another release to be followed by
> > 0.10... If the latter, I'm all for it.
> I don't know whether 0.9 aims to be the direct predecessor of 1.0 or
> not, but I would like to release a 1.0 version "soon".
> > Simply put: if we set a high standard for 1.0 and maintaining it, I'd
> > hope 0.9 to be the predecessor of 0.10, as the eventual 1.0 would IMO
> > need a fairly long stabilzation period still; however, if breaking
> > binary compatibility or changing interfaces in exiting ways will be ok
> > for post 1.0 work, or if it expected that most of the fun stuff will
> > happen on an "unstable" branch after 1.0, then 0.9 as a prelude to 1.0
> > is fine by me as well.
> Not having any experience with attempting to maintain fasl
> compatibility, apart from the observation that we find it fairly
> straightforward to fail to do so, I don't know how hard this will be
> or how much of a crimp it will put in our style.
We haven't gotten any better at figuring out how to do fasl
compatibility reliably. While I realize it's an important feature for
some kinds of things, the difficulty in doing it reliably makes me
tempted to back off to a very minimal fasl compatibility commitment.
* After 1.0, do semi-time-boxed x.y releases, between 6 months
and a year apart.
* Each x.y release gets a series of minimal patches for important
bugs that we are highly motivated to fix and where we don't think
that the patches should break fasl compatibility: 1.3patch1,
* We don't bother to fix most bugs in the fasl-compatible patch
** This could be relatively tolerable for people who use fasl
compatibility on frozen highly tested versions of their s/w.
Evidently, then, their s/w didn't exercise the bugs in 1.3,
so fasl-compatible fixes for them are not a high priority.
(And bugs for which this analysis doesn't apply -- uncommon
race conditions in GC, for example -- become particularly
good candidates for fasl-compatible fixes like 1.3patch2.)
** This is probably awkward for people who want to distribute
small executables which run everywhere. However, as near as
I can tell, today this is a small group both in the free s/w
world and in the shrinkwrap commercial s/w world; and in the
free s/w world, at least, someone who's really determined to
do this can put together binaries for every SBCL x.y in the
chronological range he cares about, and we can probably carry
on producing approximately 1.5 SBCLs per year for quite some
time before that becomes a really annoying burden to do by
hand, and even when it does, it shouldn't be hard to automate
production and testing of binaries.
* We continue the monthly x.y.z releases, and people who care about
binary compatibility are encouraged to ignore them.
> As for what 0.9-as-predecessor-to-1.0 should contain: there is a
> certain amount of discussion of this already at
> <http://sbcl-internals.cliki.net/One%20Point%20Zero>; the consensus as
> on that page appears to be that 0.9 should contain callbacks and the
> beginnings of a debugger API, in addition to what it currently holds,
> and that there are a few too many known PFDbugs for comfort. I think
> this is probably achievable in the timeframe that we're talking about
> -- two months, if I am to make some kind of 0.9 announcement in
> Amsterdam -- but it might depend on a concerted effort, so Other
> People should indicate if that requirement is not at a good time.
> (I'm thinking particularly about callbacks here; two months is perhaps
> a little tight to integrate, decide on a naming policy and test on $n$
Making an announcement of an upcoming feature-boxed 0.9 release, along
the lines of what you just suggested -- "when we have callbacks and a
draft of a debugger API, it will be 0.9, and we expect that to be soon,
possibly next month" -- seems like a reasonably conservative strategy.
I don't feel strongly about the features which should be on the list.
At one point I had ideas about what should be in 0.9, but I'm not sure
they were particularly insightful or wise. I would propose, though,
that we require both a fairly high level of consensus "we *need* this
feature" and someone who's committed to implementing that feature
quickly. The possible awkwardness of making it too hard for something
to qualify for the list doesn't seem large compared to the continuing
drawback of not incrementing the version number to reflect the
existence of things like Unicodization.
> Am I making any sense here? It's late and I've got a cold, so I
> should probably go to sleep.
Makes sense to me, but I have a cold too.:-|
William Harold Newman <william.newman@...>
"Programming should be fun, programs should be beautiful." -- Paul Graham