I like our monthly release policy, but I think we're kidding ourselves
if we pretend they are tested even remotely solidly. More then a random
revision mid-month, sure, but I don't think as many users as we hope
put SBCL put through its paces during the freeze period -- and we don't
have a solid list of things to shake at it ourselves either before we call
Monthly release cycle is also extremely rapid (I think) for people for whom
it means updating applications to when there are incompatible changes, and
even if there is nothing to fix, just testing a new SBCL for use with their
applications every month is probably a bit much a sizable percentage of our
users (users, please comment on this!)
I'm thinking that maybe we should timebox the second digit of our version
number as well. This seems topical to me since I think there has been
enough time and features since 1.0 to call in 1.1...
I'm not sure what period would be good. Maybe every 4-8, or 5-9 months?
What I would like to see would be a "real beta period":
* Freeze 1.1.beta.1. Announce it.
* Let people test it for a month or so. If there are no regressions
or major complaints, call it 1.1.0. During this time bleeding edge
development proceeds normally.
* If there ("if", hah!) is anything worth fixing, make a new beta:
1.1.beta.2 -- either with backported fixes, or take the next monthly,
whichever seems like a better bet at the time.
* Repeat as necessary -- hopefully finishing the process in less then
How does this sound? Would the better testing be worth the extra hassle?
Just to clarify, I'm more interested in a solid beta period for every 1.X
release then I am in timeboxing the same -- but I think there would be
benefits in timeboxing the period last 1.X release and the start of beta
period for next.
(Replies to sbcl-devel, please -- let's keep this on a single list. I just
wanted to canvas the user opinions as well, hence the sbcl-help.)
Get latest updates about Open Source Projects, Conferences and News.