I am responding on the dev list too :-) There's two things going on:

1) An automated build numbering -- and any build numbering for that matter -- isn't needed for official distributions. All you need is the X.Y.Z scheme where X=major,Y=minor,Z=revision versions.

2) You are actually using the build numbering to track your snapshots. That's what the build number is really for. When you use maven and attach -SNAPSHOT suffix to the version number, the libraries get deployed to the snapshot repository with an automated build number.

So two things to remember: build numbers are for development distributions only. The build number will be updated for every snapshot distribution. Once you're ready to attempt an official release, remove -SNAPSHOT and then you have the next X.Y.Z version.

Paul

Clinton Begin wrote:
The build number is very important...it's the only automated serial number we have.

It doesn't matter to me where that number comes from. SVN rev number is an excellent suggestion. But I don't want to downplay the importance of an automated serial number.

I agree with Jeff's point, that there shouldn't be two releases with the same version but different build numbers, and we never have. Perhaps a new Ant/Maven task that grabs the revision from the current working copy (because that's actually what you're building), but the task should also check that there are no modifications...it's a bit tricky to get it right actually. The alternative would be a "fresh build" task that would do a full checkout from SVN, note the rev number and then build from there. Which is actually decent.

So to summarize, yes it's important and yes it could be more meaningful by using the SVN rev number -- and it has to be automated.

Cheers,
Clinton

On 2/17/07, *Jeff Butler* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

    I agree that the build number is useless.  Apache policy says that
    there are not different versions of a release.  So we really
    shouldn't have 2.3.0-638 and 2.3.0-677, we only have one 2.3.0
    release (we've only broken that rule one time that I remember).
I kind of like the way Derby does it. The download is just
    Derby10.2.2.0, and they add the SVN revision number in the manifest
    Bundle-Version property (e.g. 10.2.2000000.485682).  I haven't
    looked at their build to see how they get the SVN number into the
    manifest - hopefully it's not a manual hack.
I'd like to keep the version number on the name of the JAR file like
    we're doing now (ibatis-2.3.0.jar) - just lose the build number.
Jeff Butler On 2/17/07, *Larry Meadors* <[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>> wrote:

        OK, as I am digging through this, I see that we have this "build
        number" thing on the download.

        I am wondering if we should change it to make that number have
        some more value.

        What I mean is: "What does 'ibatis-2.3.0.677.zip' really tell me
        about
        the build?"

        677 is just an arbitrary magic number tagged onto the build.

        Should we use something like the SVN release number instead?
        That way,
        I can very easily look to see *exactly* what has changed between
        releases by doing this:

          svn diff old:new

        That seems a lot more useful than 638 or 677.

        Thoughts? I am going to do the next release that way instead
        unless I
        hear wailing and gnashing of teeth.

        Larry



Reply via email to