ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <pbened...@apache.org>
Subject Re: iBATIS for Java 2.3.0 General Availability
Date Sat, 17 Feb 2007 19:58:34 GMT
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* <jeffgbutler@gmail.com 
> <mailto:jeffgbutler@gmail.com>> 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* <lmeadors@apache.org
>     <mailto:lmeadors@apache.org>> 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
> 
> 
> 

Mime
View raw message