I like it a lot. This is definitely something I want to be able to do with
our (internal) nant builds so we can easily identify our build type and
config from the binaries.

If you are fine contributing it, I think we can review it and put it under
source control.

Please post a compressed patch or the a files, and we'll take care of it.

Thanks,
Scott
----- Original Message ----- 
From: "Wenig, Stefan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, November 22, 2003 1:41 AM
Subject: [nant-dev] functionality of version task


hi,

since i needed a versioning scheme other than that of the existing version
task, i built my own. i like the way it works, so im suggesting this as an
extension to the existing version task.

the idea is to have a version-config file that contains not only the counter
for the incrementing part of the version number, but also the rules that
says how the rest of the version number should look.

an example of a version config file i use is as follows:

<?xml version="1.0" encoding="UTF-8" ?>
<buildversion xmlns="urn:rubicon-it:nant:buildversion">
  <major>0</major>
  <minor>9</minor>
  <build>
    <increment currentValue="13" />
  </build>
  <revision>
    <map property="nant.settings.currentframework">
      <entry propertyvalue="net-1.0" versionvalue="10" />
      <entry propertyvalue="net-1.1" versionvalue="11" />
      <default fail="true" />
    </map>
    <map property="project.config">
      <entry propertyvalue="release" versionvalue="1" />
      <entry propertyvalue="debug" versionvalue="2" />
      <entry propertyvalue="documentation" versionvalue="0" />
      <entry propertyvalue="" versionvalue="0" />
      <default fail="true" />
    </map></revision>
</buildversion>

this would result in version number of 0.9.14.101 for a release buld for
.net framework 1.0, or 0.9.13.101 if i supress incrementing. the advantage
is that if i look at the metadata of an assembly that uses one of the target
assemblies of this build, i can tell immediately which configuration is
referenced.
this could be extended to include tags for date/time values. or, more
generally, it could be extended to include simple property expansion, and
nant could provide properties with current date/time values by default.
AFAIU, any of these enhancements would provide the current functionality of
the version task and more.

my implementation of this task provides properties for the whole version
number, each part (minor, major etc) and a version number that does not
include configuration-specific values (.noconfig property).
in the example above, the latter would be 0.9.13.0, so that target directory
trees can be built like
0.9.13.0/net-1.0/debug
0.9.13.0/net-1.0/release
0.9.13.0/net-1.1/debug
etc.
also, the task allows supressoin of version incrementation.

usage example:

<buildversion versionfile="build/buildversion.xml" property="buuild.version"
increment="false" />
<property name="build.basedir"
value="${solution.basedir}/build/${build.version.noconfig}" />

i'd like to know if you think this functionality should be part of the nant
version functionality, a alternative one in nant contribs, or neither. once
more, i don't find the time to struggle with the details of contribution
right now, but i'll provide source code on request (just a few lines of code
anyway).

stefan




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Reply via email to