Re: [Sbcl-devel] Thinking out loud about SBCL release policy

[Cyrus H. <ch...@bo...>]

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? 1.1.0.0?

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.

Cyrus

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  
>> 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
>> 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.
>
>
> Michael
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Sbcl-devel mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel