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