----- 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 50000 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 00001 (00002, ...). 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
