ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler" <jeffgbut...@gmail.com>
Subject Re: [JDBC type = ARRAY / Java type = ?] iBATIS for Java 2.3.0 General Availability
Date Sat, 17 Feb 2007 14:44:03 GMT
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-638and
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> 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