I tend to agree with Michael's numbering comments and I don't like the
idea that 1.1.0 is different from 1.1. What's next? 126.96.36.199?
Also, I think the monthly release thing is a useful construct to have
stable-ish versions on a consistent basis. What I would like to see,
however, is more 2-digit (well, 2-part-number anyway) releases. The
1.0 release generated a lot of buzz and there's been a lot of good
work since then. IMO, it makes perfect sense to plan for a 1.1 release
based on things that are already in the tree with the notion that this
release would get a bit more testing than usual and, importantly, a
fresh set of binary builds for all platforms we care about (and maybe
some we don't). But I don't think we need to change the whole way we
do releases to accomplish this.
On Jan 10, 2008, at 1:24 AM, Michael Weber wrote:
> [erroneously sent as PM only]
> On Jan 9, 2008, at 21:03 , Nikodemus Siivola wrote:
>> I like our monthly release policy, but I think we're kidding
>> if we pretend they are tested even remotely solidly. More then a
>> 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
>> have a solid list of things to shake at it ourselves either before
>> we call
>> it good.
> It would be the first time (that I know of) that shifting around
> release cycles or version naming will change that. If you want
> better tested releases, you can't rely on random users alone.
>> 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!)
> Maybe a monthly release cycle is rapid, but I like the regular
> releases. I am free to (and I do) ignore releases and test only
> every other, or pick those which have interesting improvements to
> me. At least new features get pushed out regularly. Every two
> months would be good as well, I guess. But opting for longer release
> cycles means that more new features are cramped into a release, and
> it might become harder to isolate interactions between them. Think
> "I want feature X, but feature Y is currently broken": if X and Y are
> in the same release, I have to resort to CVS?
>> * Freeze 1.1.beta.1. Announce it.
> Disclaimer: I believe that version numbers are mostly for machines,
> to be able to sort releases, have automatic update procedures, etc..
> For me as a user, they are mostly opaque tags. I will perhaps
> remember that "sbcl-0.8.16 was stable, and useful for ancient
> kernels", or "I am running foo-3456alpha2 without problems", but
> that's about it. They have no other meaning. "1.0" means nothing
> more to me than "0.9.42" in terms of bug-freeness or stability (case
> in point: linux kernels with low patchlevels numbers, OS X 10.5.0,
> etc.). On the other hand, a developer might want to be able to spot
> easily that 1.3.42 is some random CVS release.
> How do you sort "1.1.beta.1" vs. "1.1.0"? This will inflict pain on
> packagers. You might say that you don't care (fair enough), or that
> they should not package "1.1.beta.1" (it will happen anyway), but
> this is quite avoidable.
> If you want to go ahead with your proposal, at least choose some
> machine-friendly scheme, like even minor numbers (with versions like:
> major.minor.patchlevel) for public releases vs. odd minor numbers for
> "beta releases". Or rather, odd minor versions for CVS commits.
> E.g., "1.1.42" means "42nd commit in preparation for 1.2.0". Then
> "1.2.0" is released, CVS becomes "1.3.0", ..., "1.3.10", etc.. Then
> "1.4.0" is released.
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> Sbcl-devel mailing list