18 Dec
2005
18 Dec
'05
10:42 p.m.
I would imagine the Build Number is added by the Compiler.
On 12/18/05, David Hinz <post.center(a)gmail.com> wrote:
Well, I was just talking about these 4 digits, the
individual build
number, I never noticed the other numbers.
TwoTailedFox schrieb:
--
"I had a handle on life, but then it broke"
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(a)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
_______________________________________________
ros-general mailing list
ros-general(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-general