Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 9671 invoked from network); 17 Feb 2007 19:52:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Feb 2007 19:52:30 -0000 Received: (qmail 25265 invoked by uid 500); 17 Feb 2007 19:52:37 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 25251 invoked by uid 500); 17 Feb 2007 19:52:37 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 25240 invoked by uid 99); 17 Feb 2007 19:52:37 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 17 Feb 2007 11:52:37 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of clinton.begin@gmail.com designates 66.249.82.225 as permitted sender) Received: from [66.249.82.225] (HELO wx-out-0506.google.com) (66.249.82.225) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 17 Feb 2007 11:52:26 -0800 Received: by wx-out-0506.google.com with SMTP id t14so1390294wxc for ; Sat, 17 Feb 2007 11:52:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Zvl+oPAJpvzjfv7CgIKshJJWKksuRVATRixHqLu1oyYW4dCfdv3GjZCDTh8f+QSkIBpGXVptyzMFWeGckKSSDOby4U95elrp5kUc1ak2+v2TyILepTaIAywW6XV+gWQsScYktcLC9vSFA2laRhGUZcVv8HoTkV7F/QHUwrFh4vY= Received: by 10.114.202.15 with SMTP id z15mr2413650waf.1171741924999; Sat, 17 Feb 2007 11:52:04 -0800 (PST) Received: by 10.114.135.7 with HTTP; Sat, 17 Feb 2007 11:52:04 -0800 (PST) Message-ID: <16178eb10702171152r71147edejac2c43422cc359fc@mail.gmail.com> Date: Sat, 17 Feb 2007 12:52:04 -0700 From: "Clinton Begin" To: user-java@ibatis.apache.org Subject: Re: [JDBC type = ARRAY / Java type = ?] iBATIS for Java 2.3.0 General Availability In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13592_6508876.1171741924941" References: <8995718.post@talk.nabble.com> <2fe5ef5b0702152209p547f6d99icaff8f298b9a5048@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_13592_6508876.1171741924941 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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 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 > > > > > > ------=_Part_13592_6508876.1171741924941 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> 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 > 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



------=_Part_13592_6508876.1171741924941--