Re: [nant-dev] RE: NAnt version number

2003-07-11 Thread Gert Driesen

- Original Message - 
From: John Barstow [EMAIL PROTECTED]
To: 'Gert Driesen' [EMAIL PROTECTED]
Cc: Nant-Developers (E-Mail) [EMAIL PROTECTED]
Sent: Friday, July 11, 2003 3:50 AM
Subject: [nant-dev] RE: NAnt version number


 Gert Driesen [mailto:[EMAIL PROTECTED] wrote:
  I'm not sure about this, but wasn't it the intention to using the
 following
  version numbering scheme :

  major.minor.revision.YMMDD

  eg. 0.8.3.30710 (if a release would be built today) ?

  Or do you have another proposal ?

 I will be recording the RC and release revision numbers going forward,
 whatever they are.
 I don't think that we had settled on a format for the build number, just
 that we would increment and track the build number.  I somewhat randomly
 picked 5 for the RC1 branch, but haven't uploaded the tarball yet.

 My proposal is that nightly builds should have a build number of the
format:
 0.8.3.YYMMDD
 That way it's always clear that this is, in fact, a development build.  We
 should be able to add this to the daily build script to auto-increment.


The revision number is actually a five digit number, so you can't use the
format you've described.. that's why I mentioned YMMDD, and not YYMMDD

 Release candidates and releases should have the format:
 0.8.3.xx, where xx is a number that increments for every release
candidate.
 So RC1 would be 0.8.3.01, RC2 would be 0.8.3.02, etc.

You can't just have a 01 (02, ...) revision number.  It would have to be
1 (2, ...).

I would actually still prefer to use the same naming scheme for both release
candidates, releases and possible even nightly builds.

Having a revision number based on the date offers some advantages : it's
guaranteed to be unique (don't think we'll be releasing two releases on one
day), and by looking at the version number you'll know when it was released
...

 That way it's clear that this is, in fact, an officially released build
and
 is simple to note.  The release manager just needs to pass in the version
 number on the command line.  It's trivial for me to reroll the tarball if
 needed.

NAnt currently offers no task to set the version number in the AssemblyInfo
(in our case it's CommonAssemblyInfo).  I'm looking into moving the
NAntContrib asminfo task to NAnt (with much needed modifications) that would
allow us to generate the CommonAssemblyInfo.cs at build time, and thereby
allowing assemblies to use the same version number.


 I don't know what to do with CVS builds.  Subversion has nice global
 revision numbers, but I have no idea what to do without those.  Maybe we
 just use the date scheme.

I don't think we really need a separate scheme for the cvs builds, or do we
?  We just need to record the version numbers of the RC and releases, and
you already intend to do that so ...


  Should we also output the NAnt revision number when launching NAnt ?
 Yes, I think so.  People usually use that number for reporting bugs.

Ok, I'll change this ...

Gert



---
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing  more.
Download  eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers


RE: [nant-dev] RE: NAnt version number

2003-07-11 Thread Anthony LoveFrancisco
|  My proposal is that nightly builds should have a build number of the
| format:
|  0.8.3.YYMMDD
|  That way it's always clear that this is, in fact, a 
| development build.  
|  We should be able to add this to the daily build script to 
|  auto-increment.
| 
| 
| The revision number is actually a five digit number, so you 
| can't use the format you've described.. that's why I 
| mentioned YMMDD, and not YYMMDD
| 

If you are using the AL.EXE documentation, then, we still hit a hard limit
of 0 through 65534 for the revision number, What happens after 2006 ?

Can I suggest using the number of days since some reference date ? January
1, 2000, perhaps ? This should give us about 179 years to come up with a new
revision numbering scheme. :-)

We can try considering revision numbers less than 100 (or some arbitrary
value) to be official builds, while anything else would be daily builds.

Also using the leading 0's for 1, doesn't really give you 0.8.3.1.

- Ants






---
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing  more.
Download  eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers


[nant-dev] RE: NAnt version number

2003-07-10 Thread John Barstow
Gert Driesen [mailto:[EMAIL PROTECTED] wrote:
 I'm not sure about this, but wasn't it the intention to using the
following
 version numbering scheme :

 major.minor.revision.YMMDD

 eg. 0.8.3.30710 (if a release would be built today) ?

 Or do you have another proposal ?

I will be recording the RC and release revision numbers going forward,
whatever they are.
I don't think that we had settled on a format for the build number, just
that we would increment and track the build number.  I somewhat randomly
picked 5 for the RC1 branch, but haven't uploaded the tarball yet.

My proposal is that nightly builds should have a build number of the format:
0.8.3.YYMMDD
That way it's always clear that this is, in fact, a development build.  We
should be able to add this to the daily build script to auto-increment.

Release candidates and releases should have the format:
0.8.3.xx, where xx is a number that increments for every release candidate.
So RC1 would be 0.8.3.01, RC2 would be 0.8.3.02, etc.
That way it's clear that this is, in fact, an officially released build and
is simple to note.  The release manager just needs to pass in the version
number on the command line.  It's trivial for me to reroll the tarball if
needed.

I don't know what to do with CVS builds.  Subversion has nice global
revision numbers, but I have no idea what to do without those.  Maybe we
just use the date scheme.

 Should we also output the NAnt revision number when launching NAnt ?
Yes, I think so.  People usually use that number for reporting bugs.

John C Barstow


---
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing  more.
Download  eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers