Re: Version numbering for release DECISION!

["George Georgalis" <george@xxxxxxxxx>]

On Sat, Apr 02, 2005 at 06:05:52PM +0200, Devon H. O'Dell  wrote:
>On Sat, Apr 02, 2005 at 11:01:10AM -0500, George Georgalis wrote:
>> On Sat, Apr 02, 2005 at 04:59:28PM +0200, Erik P. Skaalerud wrote:
>> >George Georgalis wrote:
>> >
>> >>Maybe I'm missing something obvious, but what exactly is the need
>> >>for a -RELEASE tag? Isn't it just the oldest date of a given -STABLE?
>> >>
>> >
>> >No. -RELEASE is a release schedule, where the code freezes and features 
>> >are being heavly tested to make sure that everything works the way it 
>> >should before the actual release is made (and thus printed on CD's etc).
>> >-STABLE are backported features from -CURRENT wich the project wants to 
>> >have in the next release.
>> 
>> I'm not real familiar with FBSD but that sounds (especially the
>> backported word) like what was being avoided in dfly. Also, what does
>> that provide that this doesn't?
>> 
>> 1.0-STABLE
>> 1.1-STABLE
>> 
>> ...when 1.0-WORKING is a viable release the 1.1-STABLE tag is made
>> to match, and 1.1-WORKING is revised until updates are slipped
>> to 1.1-STABLE or released in 1.2-STABLE. No reason not to update
>> 1.0-WORKING and 1.0-STABLE as appropriate.
>
>I guess I don't see the point of using branch tags in CVS if we
>also are going to use numbering schemes that reflect the state
>of the code. It seems both redundant and confusing, especially
>when the numbering schemes and the naming schemes don't line up
>(as in this example).
>

I guess I thought the numbering schemes where branches, not separate
positories. Yes, redundant and confusing to use both. I'm not very
experienced with cvs, but other than unsegmented positories (just
one big one) I don't see a downside to using cvs tags to manage the
numbering schemes. Seem simpler. -- I'm not suggesting the sort of
branching that requires joining (which sounds bad), but branches which
are only for separate releases (x.y-{UNSTABLE,WORKING,STABLE}).

Looking at the project code this way creates an interesting phenomon,
which I think is very much in line with Matt's development model,
namely there is only one HEAD: the highest numbered x.y-UNSTABLE tag.
x.y-{WORKING,STABLE} tags denote applicable file revision sets.

I don't know if or how Matt's new single file release script will
apply here, or if this method just reintroduces the problem it was to
aleviate... and I've not implemented a code base like I'm describing,
not sure what flaws or limitations would be..

// George 


-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george@xxxxxxxxx