Re: [nant-dev] RE: NAnt version number
- 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 : > > > ...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] For review - 0.8.3 rc1 release notes
I've incorporated everyone's comments and am rolling the tarball now. Thanks for the feedback. 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
[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 : > ...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
Re: [nant-dev] Problem with the task
On Thu, 2003-07-10 at 22:33, Giuseppe Greco wrote:
> Hi all,
Ah, I've also checked out the latest version of Mono
from CVS...
Gius_.
>
> I've checked out the latest version of NAnt from
> CVS right now... and the task doesn't function
> correctly anymore. This is my task:
>
>input="${module}.resx"
> output="${module}.${culture}.resources"
> todir="${build.dir}/${package.name}/bin/${culture}"/>
>
> The resulting .resource file is not placed in the
> directory specified in the todir property. Instead, the
> generated file is just saved into the current directory.
>
> Before the update of today, the task was running
> correctly.
>
> Gius_.
--
Giuseppe Greco
::agamura::
phone: +41 (0)91 604 67 65
mobile: +41 (0)76 390 60 32
email: [EMAIL PROTECTED]
web:www.agamura.com
---
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] Problem with the task
Hi all, I've checked out the latest version of NAnt from CVS right now... and the task doesn't function correctly anymore. This is my task: The resulting .resource file is not placed in the directory specified in the todir property. Instead, the generated file is just saved into the current directory. Before the update of today, the task was running correctly. Gius_. -- Giuseppe Greco ::agamura:: phone: +41 (0)91 604 67 65 mobile: +41 (0)76 390 60 32 email: [EMAIL PROTECTED] web:www.agamura.com --- 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] Behavior of New Solution Task
I just got a build working of NAnt version 0.8.4 so I could use the new solution task. Much to my surprise, I noticed that all dll files referenced by my projects are copied into my build directory (approximately 111 of them), including all the System.*.dll files! Is this normal behavior? Shouldn't there be a way to turn off copying of dll files that belong to the .NET framework? <:> Aaron Jensen <:> [EMAIL PROTECTED] <:> 800.237.6335 ext 421 <:> Financial Profiles <:> www.profiles.com --- 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] NAnt version number
John, I'm not sure about this, but wasn't it the intention to using the following version numbering scheme : ...YMMDD eg. 0.8.3.30710 (if a release would be built today) ? Or do you have another proposal ? Are we currently keeping track of the version numbers (the revision numbers actually) of the release candidates too ? We should be able to identify the NAnt version (release or RC or nightly build) that a user has. Should we also output the NAnt revision number when launching NAnt ? Currently, only the major, minor and build parts of the version number are shown. eg. NAnt version 0.8.4 Copyright (C) 2001-2003 Gerry Shaw http://nant.sourceforge.net This does not allow us to identify it the user is running a nightly build, a release candidate or a release of NAnt. 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/bulletproofapps ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
