Re: [ros-dev] Why??

[David Hinz]

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

TwoTailedFox schrieb:
>   0.2.9 not good enough as a Version Number?
>  
>  On 12/18/05, David Hinz <post.center(a)gmail.com> wrote:
> >   I was talking about numbering the releases...
> >
> >  TwoTailedFox schrieb:
> > >   We have SVN Numbers o.o
> > >
> > >  On 12/18/05, David Hinz <post.center(a)gmail.com> wrote:
> > > > Why don't we use buildnumbers?
> > > > Without any sense, just counting a number up and creating some major
> > > > releases with names from time to time.
> > > >
> > > > Just an idea...
> > > >
> > > > Greets,
> > > >
> > > > David Hinz 
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>  
>  
>  --
>  "I had a handle on life, but then it broke"
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[TwoTailedFox]

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
>
>  TwoTailedFox schrieb:
> >   0.2.9 not good enough as a Version Number?
> >
> >  On 12/18/05, David Hinz <post.center(a)gmail.com> wrote:
> > >   I was talking about numbering the releases...
> > >
> > >  TwoTailedFox schrieb:
> > > >   We have SVN Numbers o.o
> > > >
> > > >  On 12/18/05, David Hinz <post.center(a)gmail.com> wrote:
> > > > > Why don't we use buildnumbers?
> > > > > Without any sense, just counting a number up and creating some major
> > > > > releases with names from time to time.
> > > > >
> > > > > Just an idea...
> > > > >
> > > > > Greets,
> > > > >
> > > > > David Hinz 
> > >  _______________________________________________
> > >  Ros-dev mailing list
> > >  Ros-dev(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > >  
> >
> >  --
> >  "I had a handle on life, but then it broke"
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>  _______________________________________________
>  ros-general mailing list
>  ros-general(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-general
>  

--
"I had a handle on life, but then it broke"

[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(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

[TwoTailedFox]

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:
> >   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
>  

--
"I had a handle on life, but then it broke"

[David Hinz]

I think, the whole thing would just need a whole bunch of scripts, then 
it wouldn't be much work, as nearly everything can be automated, e.g. 
the compiling, the buildnumber, just not some release specific things, 
like a release name or something like that.

Greets,

David Hinz

TwoTailedFox schrieb:
>   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]

Have these custom settings saveed in XML File in SVN Trunk Root?

On 12/18/05, David Hinz <post.center(a)gmail.com> wrote:
>   I think, the whole thing would just need a whole bunch
> of scripts, then
>  it wouldn't be much work, as nearly everything can be automated, e.g.
>  the compiling, the buildnumber, just not some release specific things,
>  like a release name or something like that.
>
>  Greets,
>
>  David Hinz
>
>  TwoTailedFox schrieb:
> >   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. 
> _______________________________________________
>  ros-general mailing list
>  ros-general(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-general
>  

--
"I had a handle on life, but then it broke"

[David Hinz]

I'm sorry, I don't really understand your question.

Could you try to explain it a bit more?

TwoTailedFox schrieb:
>   Have these custom settings saveed in XML File in SVN
> Trunk Root?
>  
>  On 12/18/05, David Hinz <post.center(a)gmail.com> wrote:
> >   I think, the whole thing would just need a whole
> > bunch of scripts, then
> >  it wouldn't be much work, as nearly everything can be automated, e.g.
> >  the compiling, the buildnumber, just not some release specific things,
> >  like a release name or something like that.
> >
> >  Greets,
> >
> >  David Hinz
> >
> >  TwoTailedFox schrieb:
> > >   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. 
> > _______________________________________________
> >  ros-general mailing list
> >  ros-general(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-general
> >  
>  
>  
>  --
>  "I had a handle on life, but then it broke"
>  
>  _______________________________________________
>  ros-general mailing list
>  ros-general(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-general
>

[TwoTailedFox]

That actually wasn't supposed to have a '?' there.

I mean, why not include variable data, such as Version Numbers, and
descriptions, in an XML file that is read upon compile?

On 12/18/05, David Hinz <post.center(a)gmail.com> wrote:
>   I'm sorry, I don't really understand your
> question.
>
>  Could you try to explain it a bit more?
>
>  TwoTailedFox schrieb:
> >   Have these custom settings saveed in XML File in
> > SVN Trunk Root?
> >
> >  On 12/18/05, David Hinz <post.center(a)gmail.com> wrote:
> > >   I think, the whole thing would just need a whole
> > > bunch of scripts, then
> > >  it wouldn't be much work, as nearly everything can be automated, e.g.
> > >  the compiling, the buildnumber, just not some release specific things,
> > >  like a release name or something like that.
> > >
> > >  Greets,
> > >
> > >  David Hinz
> > >
> > >  TwoTailedFox schrieb:
> > > >   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. 
> > > _______________________________________________
> > >  ros-general mailing list
> > >  ros-general(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-general
> > >  
> >
> >  --
> >  "I had a handle on life, but then it broke"
> >
> >  _______________________________________________
> >  ros-general mailing list
> >  ros-general(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-general
> >  
>  _______________________________________________
>  ros-general mailing list
>  ros-general(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-general
>  

--
"I had a handle on life, but then it broke"

[David Hinz]

This seems to be a good idea, tis way it would be easy to change some
settings and even modes, for example we could create one option, where
you select the release mode, e.g. 0 for the ordinary svn-compilations,
1 for a weekly tech preview and 2 for a release.
This can change some settings like dgb, kdbg and platform
optimisations, and some places in ReactOS where the release name is
output, and even some settings of usetup.

Sounds like a good idea, but I think we should use the existing
ReactOS.xml (if you have one...), so we don't need to create a new
file for this.

Greets,

David Hinz

2005/12/19, TwoTailedFox <twotailedfox(a)gmail.com>om>:
>   That actually wasn't supposed to have a
> '?' there.
>
>  I mean, why not include variable data, such as Version Numbers, and
>  descriptions, in an XML file that is read upon compile?
>
>  On 12/18/05, David Hinz <post.center(a)gmail.com> wrote:
> >   I'm sorry, I don't really understand your
> > question.
> >
> >  Could you try to explain it a bit more?
> >
> >  TwoTailedFox schrieb:
> > >   Have these custom settings saveed in XML File in
> > > SVN Trunk Root?
> > >
> > >  On 12/18/05, David Hinz <post.center(a)gmail.com> wrote:
> > > >   I think, the whole thing would just need a whole
> > > > bunch of scripts, then
> > > >  it wouldn't be much work, as nearly everything can be automated, e.g.
> > > >  the compiling, the buildnumber, just not some release specific things,
> > > >  like a release name or something like that.
> > > >
> > > >  Greets,
> > > >
> > > >  David Hinz
> > > >
> > > >  TwoTailedFox schrieb:
> > > > > 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.
> > > >  _______________________________________________
> > > >  ros-general mailing list
> > > >  ros-general(a)reactos.org
> > > >  http://www.reactos.org/mailman/listinfo/ros-general
> > > >  
> > >
> > >  --
> > >  "I had a handle on life, but then it broke"
> > >
> > >  _______________________________________________
> > >  ros-general mailing list
> > >  ros-general(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-general
> > >  
> >  _______________________________________________
> >  ros-general mailing list
> >  ros-general(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-general
> >  
>
>  --
>  "I had a handle on life, but then it broke"
>
>  _______________________________________________
>  ros-general mailing list
>  ros-general(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-general
>

[David Hinz]

Saw a little mistake in my mail:

On 12/18/05, David Hinz <post.center(a)gmail.com> wrote:

>   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. 
It should be weekly technology previews, not daily, sorry...

Greets,

David Hinz