[ros-general] Re: [ros-dev] Why??

[David Hinz]

Well, I was just talking about these 4 digits, the individual build 
number, I never noticed the other numbers.

TwoTailedFox schrieb:
> The Build Numbers in Windows XP arn't nonsense.
> 
> 2600 is the Individual Build Number. The first set of six numbers is
> the date the build was compiled on, written in yy/mm/dd format. The
> final set of four numbers are the time that the compile finished,
> written in 24 Hour Time Format.
> 
> On 12/18/05, David Hinz <post.center at gmail.com> wrote:
>> Well, I'm fine with it, but some other people seem to have problems with
>> this system, so I thought of something without any sense, just numbers.
>>
>> Like the build-numbers every MS-product has, e.g. Win XP has the
>> build-number 2600
>>
>> I would be more for a mix of a lot of different systems.
>>
>> Create daily technology preview, that don't need to be "perfect", if
>> they compile fine, they can be released. This would be the ones with the
>> buildnumbers.
>> Then there were monthly releases, or maybe a release every month with
>> the current numbering system, but also with buildnumbers.
>>
>> And then we have the releases with codenames.
>>
>> So as an example this all could look like this:
>>
>> 02.01.2006: Technology Preview: Build 0001 r20500
>> 09.01.2006: Technology Preview: Build 0002 r20619
>> 16.01.2006: Technology Preview: Build 0003 r20681
>> 23.01.2006: Technology Preview: Build 0004 r20834
>> 30.01.2006: Technology Preview: Build 0005 r21001
>> ...
>> 20.02.2006: Technology Preview: Build 0008 r21517
>> 27.02.2006: Release 0.2.10: Build 0009 r21687
>> 06.03.2006: Technology Preview: Build 0010 r21755
>> ...
>> ...
>> 17.04.2006: Technology Preview: Build 0016 r22033
>> 24.04.2006: Release 0.3.0: Build 0017 r22177 Codename God knows
>> 01.05.2006: Technology Preview: Build 0018 r22257
>>
>> You see, I would choose a weekly release plan.
>>
>> The whole organisation on SVN would look a bit like this:
>>
>> We have trunk, which would be our unstable tree.
>> Then we have our testing tree, which always has to compile fine and
>> should at least boot and install fine too.
>> This branch would be feature freezed for one day every week, and after
>> this the Technology Preview would be released.
>> In addition, the ordinary two monthly releases would be created out of
>> this branch, we would just feature freeze it for a whole week and the
>> last 3 days of the week it would be codefreezed, so on the whole it
>> would be feature freezed for 8 days (including the one day before the
>> last Technology Preview) and of this 8 days it would be code freezed for
>> 3 days (the last 3 days before the release).
>> So an ordinary release would be a Technology Preview, but in the week
>> before its release the branch would be handled a bit differently than in
>> other weeks.
>>
>> I hope I didn't confuse you all too much, but for me this seems like a
>> good idea.
>>
>> Comments are highly appreciated.
>>
>> Greets,
>>
>> David Hinz