Re: [Sbcl-devel] time-boxing sbcl-1.0

[Richard N. <hol...@gm...>]

> 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...

Thank you for the invitation, Bill :)

As someone who uses SBCL both personally and in the enterprise, and =20
has sponsored work on it, my opinion is probably relevant.

I am quite happy with SBCL's current process (monthly releases, =20
incremental development), for a number of reasons. Here are some =20
unorganized thoughts.

=95 I don't see much SBCL software distributed as FASLs. Much of the =20
motivation for FASL compatibility seems to be missing, then.

=95 Older versions of SBCL are freely available, and are really no less =20=

maintained than the latest -- which is to say, you don't lose "vendor =20=

support" just because you're running an earlier version. This makes a =20=

common practice -- test your upgrades before you do them -- even more =20=

reasonable, because you have no race against time.

=95 I haven't experienced much gratuitous breakage -- I have two =20
servers, one running 0.9.4 on Linux and one running 0.9.15 on Solaris =20=

x86, and they are both using the same source libraries -- indeed, the =20=

same libraries I'm using on my 0.9.11 MacBook Pro. I don't recall =20
making any repairs due to internals changes in SBCL. (It's also good =20
practice not to depend on internals anyway!)  I think that's a great =20
record.

=95 Incremental development along one branch prevents undue spread of =20=

developer effort. Multiple branches, unless a product really is =20
feature-complete, also do more harm than good -- at some point you =20
need a feature that's in a later branch, and then you have to do your =20=

porting in one go, or backport (which is ridiculous, as it starts =20
creating forks).


Would it be good to have people keeping old versions secure and =20
reliable? Sure. Is it likely to happen? Not really, thanks to Bill's =20
point about developers' itches. Is it likely to happen without =20
harming mainline development? Almost certainly not, because funded =20
work on SBCL internals is infrequent.

That said, a 1.0 release should carry some kind of burden. I suggest =20
that burden should be a longer feature freeze and thorough =20
documentation* -- it should be a milestone against which conformance, =20=

performance, and architecture can be measured, and a moment for =20
taking stock.

It should probably also be a "buy the maintainers beer" moment. I =20
don't expect any arguments on that front :)

-R


* README, INSTALL, MISSING and BUGS, if nothing else -- I'm not =20
expecting magical documentation fairies to appear and start writing =20
hundreds of pages of text, but a "state of the nation" is important.=