You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by Jeff Butler <je...@gmail.com> on 2007/02/12 01:42:50 UTC
iBATIS for Java 2.3.0 General Availability
The votes are in an iBATIS for Java version 2.3.0 is declared to be Apache
general availability status.
This release is the first release that does not include the DAO framework.
The DAO framework is available as a separate download on the Java downloads
page, but we recommend migrating to Spring framework based DAOs.
The official announcement will be reflected on the website within the next
hour, and you can download it from
http://ibatis.apache.org/javadownloads.cgi.
If you've been using 2.3.0 already, there's no need to download it again -
it is the same JAR.
Enjoy!
Jeff Butler
Re: iBATIS for Java 2.3.0 General Availability
Posted by Clinton Begin <cl...@gmail.com>.
>> Spring framework based DAOs.
Or your own DAO or DAL framework, or none at all. I very often choose
to write a custom one because it's very easy (maybe 4 - 8 hours max),
and sometimes it fits your environment better. More recently I've
started leaving out the DAO layer altogether. It's probably the
lowest risk abstraction to leave out of your application.
Cheers,
Clinton
On 2/11/07, Jeff Butler <je...@gmail.com> wrote:
> The votes are in an iBATIS for Java version 2.3.0 is declared to be Apache
> general availability status.
>
> This release is the first release that does not include the DAO framework.
> The DAO framework is available as a separate download on the Java downloads
> page, but we recommend migrating to Spring framework based DAOs.
>
> The official announcement will be reflected on the website within the next
> hour, and you can download it from
> http://ibatis.apache.org/javadownloads.cgi.
>
> If you've been using 2.3.0 already, there's no need to download it again -
> it is the same JAR.
>
> Enjoy!
> Jeff Butler
>
Re: [JDBC type = ARRAY / Java type = ?] iBATIS for Java 2.3.0 General Availability
Posted by Clinton Begin <cl...@gmail.com>.
Sounds like a great test for our new Maven build!
Clinton
On 2/15/07, bkbonner <br...@paraware.com> wrote:
>
> Jeff, are there any plans to have the updated version published to Ibiblio?
> (specifically maven2?) Thanks!
>
> Brian
>
>
> Jeff Butler-2 wrote:
> >
> > The votes are in an iBATIS for Java version 2.3.0 is declared to be Apache
> > general availability status.
> >
> > This release is the first release that does not include the DAO framework.
> > The DAO framework is available as a separate download on the Java
> > downloads
> > page, but we recommend migrating to Spring framework based DAOs.
> >
> > The official announcement will be reflected on the website within the next
> > hour, and you can download it from
> > http://ibatis.apache.org/javadownloads.cgi.
> >
> > If you've been using 2.3.0 already, there's no need to download it again -
> > it is the same JAR.
> >
> > Enjoy!
> > Jeff Butler
> >
> >
>
> --
> View this message in context: http://www.nabble.com/iBATIS-for-Java-2.3.0-General-Availability-tf3210955.html#a8995718
> Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
>
>
Re: [JDBC type = ARRAY / Java type = ?] iBATIS for Java 2.3.0 General Availability
Posted by Clinton Begin <cl...@gmail.com>.
Signing the Jar etc. is a piece of cake. The process looks complex,
but it's really not at all.
Thanks Larry, and best of luck.
Clinton
On 2/15/07, Larry Meadors <lm...@apache.org> wrote:
> I'll raise my hand as the guinea pig^W^W pioneer to do the next
> release as an experimental maven build.
>
> If Jeff can help me with the process requirements, I can pester
> Brandon and others for maven support.
>
> Larry
>
>
> On 2/15/07, Jeff Butler <je...@gmail.com> wrote:
> > We are currently discussing the idea of moving to Maven for our build
> > process (see the dev list archives). Once we decide about that, it will be
> > easier to decide if/when we will get the Jars to ibiblio.
> >
> > For now, I doubt that 2.3.0 will make it to ibiblio. But the next release
> > of iBATIS might.
> >
> > Jeff Butler
> >
> >
> >
> > On 2/15/07, bkbonner <br...@paraware.com> wrote:
> > >
> > > Jeff, are there any plans to have the updated version published to
> > Ibiblio?
> > > (specifically maven2?) Thanks!
> > >
> > > Brian
> > >
> > >
> > > Jeff Butler-2 wrote:
> > > >
> > > > The votes are in an iBATIS for Java version 2.3.0 is declared to be
> > Apache
> > > > general availability status.
> > > >
> > > > This release is the first release that does not include the DAO
> > framework.
> > > > The DAO framework is available as a separate download on the Java
> > > > downloads
> > > > page, but we recommend migrating to Spring framework based DAOs.
> > > >
> > > > The official announcement will be reflected on the website within the
> > next
> > > > hour, and you can download it from
> > > > http://ibatis.apache.org/javadownloads.cgi.
> > > >
> > > > If you've been using 2.3.0 already, there's no need to download it again
> > -
> > > > it is the same JAR.
> > > >
> > > > Enjoy!
> > > > Jeff Butler
> > > >
> > > >
> > >
> > > --
> > > View this message in context:
> > http://www.nabble.com/iBATIS-for-Java-2.3.0-General-Availability-tf3210955.html#a8995718
> > > Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
> > >
> > >
> >
> >
>
Re: iBATIS for Java 2.3.0 General Availability
Posted by Clinton Begin <cl...@gmail.com>.
LOL.
Just saw this on DZone.
http://escx.blogspot.com/2007/02/hating-maven-less-than-ant.html
To be honest it scared me more about Maven 2, but the author still supports
it.
Clinton
On 2/17/07, Slava Imeshev <vi...@viewtier.com> wrote:
>
> In build management the generally accepted (or those to be considered OK)
> practices are:
>
> 1. Use adding a build number to product packages that are intermediate in
> nature, such as developer
> or nightly builds. The main advantage is that this allows quickly
> identifying the state of the code
> base at the moment of the build. Some also add a change list number if a
> version control
> system supports it. If the version control system doesn't support change
> lists, a version
> control time stamp may be used instead. There is no general best practice
> on the format,
> but most follow the scheme below.This naming scheme communicates well the
> temporarily/snapshot nature of the package.:
>
> <product-name>-<major>.<minor>.<patch>-<build number>-<change-list-number>
>
> The ultimate naming for iBATIS here would be ibatis-2.3.0-345-10685.jar
>
> 2. Use <product-name>-<major>.<minor>.<patch> for released product
> packages.
> This simplifies management of third-party dependencies for users,
> communication with
> support e.t.c For a product it also allows for easy branding. Usually, the
> build number and
> the change number are not required in the package names because these a
> values always
> documented through the release process. The ultimate naming for iBATIS
> here would
> be ibatis-2.3.1.jar
>
> In either case the build number and the change number are often included
> into the product
> packaging, release information on product web sites, release notes and
> "About" information.
>
> These are a couple of practices we, as a software build management
> company, recommend
> to our customers. They proved to work well over the years.
>
> Note that there is a case when using scheme number 1 is acceptable for
> released products
> when releases are small, often, with no intermediate releases, and a build
> system doesn't
> support automated management of a version number. The only example I can
> think of is
> Linux's package names.
>
> Just my two cents.
>
> Regards,
>
> Slava Imeshev
> vimeshev@viewtier.com
> www.viewtier.com
>
>
> ----- Original Message -----
> From: "Paul Benedict" <pb...@apache.org>
> To: <de...@ibatis.apache.org>
> Sent: Saturday, February 17, 2007 2:47 PM
> Subject: Re: iBATIS for Java 2.3.0 General Availability
>
>
> > Well thanks for listening at least. I suppose it is equal one way or
> > another. Perhaps I will learn something from this :-)
> >
> > Clinton Begin wrote:
> > >
> > > >> I am not aware of any other project at Apache that
> > > >> includes a build number as part of their version number.
> > >
> > > So let's teach them something together.
> > >
> > > Clinton
> > >
> > >
> > > On 2/17/07, *Paul Benedict* <pbenedict@apache.org
> > > <ma...@apache.org>> wrote:
> > >
> > > Clinton,
> > >
> > > I understand the argument, but I am not aware of any other project
> at
> > > Apache that includes a build number as part of their version
> number.
> > > That doesn't mean you're the only one, but I think it's a minority
> > > practice. And if it is a minority practice, there must be a good
> > > reason
> > > to not do it on a general basis.
> > >
> > > My point is the Build number is irrelevant to the release. If you
> > > produce snapshots until an official build, then you've eliminated
> the
> > > need for it. I never needed it, and I think eliminating it may
> ease
> > > releases. What you're essentially doing is using the build number
> > > as THE
> > > revision number. However, the revision doesn't need a promotion
> until
> > > you're ready to vote on a release. So given three releasable
> versions
> > > using your Build scheme (2.4.000, 2.4.256, 2.4.667), that's
> nothing
> > > really more than 2.4.0, 2.4.1, and 2.4.2.
> > >
> > > Paul
> > >
> > > Brandon Goodin wrote:
> > > > I talked to larry and he floated his idea on this. My main
> thought
> > > > about the build number was that it has to tie meaningfully back
> > > to the
> > > > source state. Larry's idea does that perfectly... rawk.
> > > >
> > > > Thanks,
> > > > Brandon
> > > >
> > > > On 2/17/07, *Brandon Goodin* <brandon.goodin@gmail.com
> > > <ma...@gmail.com>
> > > > <mailto: brandon.goodin@gmail.com
> > > <ma...@gmail.com>>> wrote:
> > > >
> > > > This is very interesting and I'd like to know more about why
> > > this
> > > > number is important apart from other things like a
> > > > major.minor.revision.timestamp format. I'm not really
> picking up
> > > > the importance from the previous comments. Here is my
> > > > understanding, help me to clear the fog out... The serial is
> > > used
> > > > to identify a unique build. This unique build is important
> for
> > > > tracing back to what? If we do not have an anchor in our
> source
> > > > code repository to compare it to what good does it do us?
> > > >
> > > > Brandon
> > > >
> > > >
> > > > On 2/17/07, *Clinton Begin* < clinton.begin@gmail.com
> > > <ma...@gmail.com>
> > > > <mailto:clinton.begin@gmail.com
> > > <ma...@gmail.com>>> wrote:
> > > >
> > > >
> > > > Paul,
> > > >
> > > > I disagree entirely.
> > > >
> > > > Open any product on your PC today, Java IDE, Visual
> > > > Studio...anything. It will have a build number. Not
> just
> > > > software really, any and every product on the planet has
> a
> > > > serial number. They are useful for uniquely identifying
> > > > something. The major.minor.bug release version is very
> > > > subjective and we tend to manipulate it that way. The
> > > build
> > > > number is automated and therefore more reliable as a
> > > unique ID
> > > > for the software version.
> > > >
> > > > I agree about the disconnect with SVN in the past. What
> we
> > > > typically do on commercial projects is have the CI
> server
> > > > automatically create a tag for the build in SVN. That
> solves
> > > > the disconnect issue. iBATIS hasn't had a CI server
> until
> > > > recently, so the tagging was manual. Now we do have a
> CI
> > > > server and can automate the relationship one way or
> another
> > > > (either tag SVN with the build number or pul the rev
> number
> > > > from SVN and tag the build with that).
> > > >
> > > > It's important to me and easy to produce. So regardless
> of
> > > > what build system we use, I'd like to ensure that a
> build
> > > > number is represented on the deployable ZIP filename,
> > > the JAR
> > > > file names the manifest file and the release.txt .
> > > >
> > > > Clinton
> > > >
> > > >
> > > >
> > > > On 2/17/07, *Paul Benedict* < pbenedict@apache.org
> > > <ma...@apache.org>
> > > > <mailto: pbenedict@apache.org
> > > <ma...@apache.org>>> wrote:
> > > >
> > > > 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
> > > <ma...@gmail.com>
> > > > <mailto:jeffgbutler@gmail.com
> > > <ma...@gmail.com>>
> > > > > <mailto:jeffgbutler@gmail.com
> > > <ma...@gmail.com>
> > > > <mailto:jeffgbutler@gmail.com
> > > <ma...@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 <ma...@apache.org>
> > > > <mailto:lmeadors@apache.org
> > > <ma...@apache.org>>
> > > > > <mailto: lmeadors@apache.org
> > > <ma...@apache.org>
> > > > <mailto:lmeadors@apache.org
> > > <ma...@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
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
>
Re: iBATIS for Java 2.3.0 General Availability
Posted by Slava Imeshev <vi...@viewtier.com>.
In build management the generally accepted (or those to be considered OK) practices are:
1. Use adding a build number to product packages that are intermediate in nature, such as developer
or nightly builds. The main advantage is that this allows quickly identifying the state of the code
base at the moment of the build. Some also add a change list number if a version control
system supports it. If the version control system doesn't support change lists, a version
control time stamp may be used instead. There is no general best practice on the format,
but most follow the scheme below.This naming scheme communicates well the
temporarily/snapshot nature of the package.:
<product-name>-<major>.<minor>.<patch>-<build number>-<change-list-number>
The ultimate naming for iBATIS here would be ibatis-2.3.0-345-10685.jar
2. Use <product-name>-<major>.<minor>.<patch> for released product packages.
This simplifies management of third-party dependencies for users, communication with
support e.t.c For a product it also allows for easy branding. Usually, the build number and
the change number are not required in the package names because these a values always
documented through the release process. The ultimate naming for iBATIS here would
be ibatis-2.3.1.jar
In either case the build number and the change number are often included into the product
packaging, release information on product web sites, release notes and "About" information.
These are a couple of practices we, as a software build management company, recommend
to our customers. They proved to work well over the years.
Note that there is a case when using scheme number 1 is acceptable for released products
when releases are small, often, with no intermediate releases, and a build system doesn't
support automated management of a version number. The only example I can think of is
Linux's package names.
Just my two cents.
Regards,
Slava Imeshev
vimeshev@viewtier.com
www.viewtier.com
----- Original Message -----
From: "Paul Benedict" <pb...@apache.org>
To: <de...@ibatis.apache.org>
Sent: Saturday, February 17, 2007 2:47 PM
Subject: Re: iBATIS for Java 2.3.0 General Availability
> Well thanks for listening at least. I suppose it is equal one way or
> another. Perhaps I will learn something from this :-)
>
> Clinton Begin wrote:
> >
> > >> I am not aware of any other project at Apache that
> > >> includes a build number as part of their version number.
> >
> > So let's teach them something together.
> >
> > Clinton
> >
> >
> > On 2/17/07, *Paul Benedict* <pbenedict@apache.org
> > <ma...@apache.org>> wrote:
> >
> > Clinton,
> >
> > I understand the argument, but I am not aware of any other project at
> > Apache that includes a build number as part of their version number.
> > That doesn't mean you're the only one, but I think it's a minority
> > practice. And if it is a minority practice, there must be a good
> > reason
> > to not do it on a general basis.
> >
> > My point is the Build number is irrelevant to the release. If you
> > produce snapshots until an official build, then you've eliminated the
> > need for it. I never needed it, and I think eliminating it may ease
> > releases. What you're essentially doing is using the build number
> > as THE
> > revision number. However, the revision doesn't need a promotion until
> > you're ready to vote on a release. So given three releasable versions
> > using your Build scheme (2.4.000, 2.4.256, 2.4.667), that's nothing
> > really more than 2.4.0, 2.4.1, and 2.4.2.
> >
> > Paul
> >
> > Brandon Goodin wrote:
> > > I talked to larry and he floated his idea on this. My main thought
> > > about the build number was that it has to tie meaningfully back
> > to the
> > > source state. Larry's idea does that perfectly... rawk.
> > >
> > > Thanks,
> > > Brandon
> > >
> > > On 2/17/07, *Brandon Goodin* <brandon.goodin@gmail.com
> > <ma...@gmail.com>
> > > <mailto: brandon.goodin@gmail.com
> > <ma...@gmail.com>>> wrote:
> > >
> > > This is very interesting and I'd like to know more about why
> > this
> > > number is important apart from other things like a
> > > major.minor.revision.timestamp format. I'm not really picking up
> > > the importance from the previous comments. Here is my
> > > understanding, help me to clear the fog out... The serial is
> > used
> > > to identify a unique build. This unique build is important for
> > > tracing back to what? If we do not have an anchor in our source
> > > code repository to compare it to what good does it do us?
> > >
> > > Brandon
> > >
> > >
> > > On 2/17/07, *Clinton Begin* < clinton.begin@gmail.com
> > <ma...@gmail.com>
> > > <mailto:clinton.begin@gmail.com
> > <ma...@gmail.com>>> wrote:
> > >
> > >
> > > Paul,
> > >
> > > I disagree entirely.
> > >
> > > Open any product on your PC today, Java IDE, Visual
> > > Studio...anything. It will have a build number. Not just
> > > software really, any and every product on the planet has a
> > > serial number. They are useful for uniquely identifying
> > > something. The major.minor.bug release version is very
> > > subjective and we tend to manipulate it that way. The
> > build
> > > number is automated and therefore more reliable as a
> > unique ID
> > > for the software version.
> > >
> > > I agree about the disconnect with SVN in the past. What we
> > > typically do on commercial projects is have the CI server
> > > automatically create a tag for the build in SVN. That solves
> > > the disconnect issue. iBATIS hasn't had a CI server until
> > > recently, so the tagging was manual. Now we do have a CI
> > > server and can automate the relationship one way or another
> > > (either tag SVN with the build number or pul the rev number
> > > from SVN and tag the build with that).
> > >
> > > It's important to me and easy to produce. So regardless of
> > > what build system we use, I'd like to ensure that a build
> > > number is represented on the deployable ZIP filename,
> > the JAR
> > > file names the manifest file and the release.txt .
> > >
> > > Clinton
> > >
> > >
> > >
> > > On 2/17/07, *Paul Benedict* < pbenedict@apache.org
> > <ma...@apache.org>
> > > <mailto: pbenedict@apache.org
> > <ma...@apache.org>>> wrote:
> > >
> > > 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
> > <ma...@gmail.com>
> > > <mailto:jeffgbutler@gmail.com
> > <ma...@gmail.com>>
> > > > <mailto:jeffgbutler@gmail.com
> > <ma...@gmail.com>
> > > <mailto:jeffgbutler@gmail.com
> > <ma...@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 <ma...@apache.org>
> > > <mailto:lmeadors@apache.org
> > <ma...@apache.org>>
> > > > <mailto: lmeadors@apache.org
> > <ma...@apache.org>
> > > <mailto:lmeadors@apache.org
> > <ma...@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
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
Re: iBATIS for Java 2.3.0 General Availability
Posted by Paul Benedict <pb...@apache.org>.
Well thanks for listening at least. I suppose it is equal one way or
another. Perhaps I will learn something from this :-)
Clinton Begin wrote:
>
> >> I am not aware of any other project at Apache that
> >> includes a build number as part of their version number.
>
> So let's teach them something together.
>
> Clinton
>
>
> On 2/17/07, *Paul Benedict* <pbenedict@apache.org
> <ma...@apache.org>> wrote:
>
> Clinton,
>
> I understand the argument, but I am not aware of any other project at
> Apache that includes a build number as part of their version number.
> That doesn't mean you're the only one, but I think it's a minority
> practice. And if it is a minority practice, there must be a good
> reason
> to not do it on a general basis.
>
> My point is the Build number is irrelevant to the release. If you
> produce snapshots until an official build, then you've eliminated the
> need for it. I never needed it, and I think eliminating it may ease
> releases. What you're essentially doing is using the build number
> as THE
> revision number. However, the revision doesn't need a promotion until
> you're ready to vote on a release. So given three releasable versions
> using your Build scheme (2.4.000, 2.4.256, 2.4.667), that's nothing
> really more than 2.4.0, 2.4.1, and 2.4.2.
>
> Paul
>
> Brandon Goodin wrote:
> > I talked to larry and he floated his idea on this. My main thought
> > about the build number was that it has to tie meaningfully back
> to the
> > source state. Larry's idea does that perfectly... rawk.
> >
> > Thanks,
> > Brandon
> >
> > On 2/17/07, *Brandon Goodin* <brandon.goodin@gmail.com
> <ma...@gmail.com>
> > <mailto: brandon.goodin@gmail.com
> <ma...@gmail.com>>> wrote:
> >
> > This is very interesting and I'd like to know more about why
> this
> > number is important apart from other things like a
> > major.minor.revision.timestamp format. I'm not really picking up
> > the importance from the previous comments. Here is my
> > understanding, help me to clear the fog out... The serial is
> used
> > to identify a unique build. This unique build is important for
> > tracing back to what? If we do not have an anchor in our source
> > code repository to compare it to what good does it do us?
> >
> > Brandon
> >
> >
> > On 2/17/07, *Clinton Begin* < clinton.begin@gmail.com
> <ma...@gmail.com>
> > <mailto:clinton.begin@gmail.com
> <ma...@gmail.com>>> wrote:
> >
> >
> > Paul,
> >
> > I disagree entirely.
> >
> > Open any product on your PC today, Java IDE, Visual
> > Studio...anything. It will have a build number. Not just
> > software really, any and every product on the planet has a
> > serial number. They are useful for uniquely identifying
> > something. The major.minor.bug release version is very
> > subjective and we tend to manipulate it that way. The
> build
> > number is automated and therefore more reliable as a
> unique ID
> > for the software version.
> >
> > I agree about the disconnect with SVN in the past. What we
> > typically do on commercial projects is have the CI server
> > automatically create a tag for the build in SVN. That solves
> > the disconnect issue. iBATIS hasn't had a CI server until
> > recently, so the tagging was manual. Now we do have a CI
> > server and can automate the relationship one way or another
> > (either tag SVN with the build number or pul the rev number
> > from SVN and tag the build with that).
> >
> > It's important to me and easy to produce. So regardless of
> > what build system we use, I'd like to ensure that a build
> > number is represented on the deployable ZIP filename,
> the JAR
> > file names the manifest file and the release.txt .
> >
> > Clinton
> >
> >
> >
> > On 2/17/07, *Paul Benedict* < pbenedict@apache.org
> <ma...@apache.org>
> > <mailto: pbenedict@apache.org
> <ma...@apache.org>>> wrote:
> >
> > 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
> <ma...@gmail.com>
> > <mailto:jeffgbutler@gmail.com
> <ma...@gmail.com>>
> > > <mailto:jeffgbutler@gmail.com
> <ma...@gmail.com>
> > <mailto:jeffgbutler@gmail.com
> <ma...@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 <ma...@apache.org>
> > <mailto:lmeadors@apache.org
> <ma...@apache.org>>
> > > <mailto: lmeadors@apache.org
> <ma...@apache.org>
> > <mailto:lmeadors@apache.org
> <ma...@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
> > >
> > >
> > >
> >
> >
> >
> >
>
>
Re: iBATIS for Java 2.3.0 General Availability
Posted by Clinton Begin <cl...@gmail.com>.
>> I am not aware of any other project at Apache that
>> includes a build number as part of their version number.
So let's teach them something together.
Clinton
On 2/17/07, Paul Benedict <pb...@apache.org> wrote:
>
> Clinton,
>
> I understand the argument, but I am not aware of any other project at
> Apache that includes a build number as part of their version number.
> That doesn't mean you're the only one, but I think it's a minority
> practice. And if it is a minority practice, there must be a good reason
> to not do it on a general basis.
>
> My point is the Build number is irrelevant to the release. If you
> produce snapshots until an official build, then you've eliminated the
> need for it. I never needed it, and I think eliminating it may ease
> releases. What you're essentially doing is using the build number as THE
> revision number. However, the revision doesn't need a promotion until
> you're ready to vote on a release. So given three releasable versions
> using your Build scheme (2.4.000, 2.4.256, 2.4.667), that's nothing
> really more than 2.4.0, 2.4.1, and 2.4.2.
>
> Paul
>
> Brandon Goodin wrote:
> > I talked to larry and he floated his idea on this. My main thought
> > about the build number was that it has to tie meaningfully back to the
> > source state. Larry's idea does that perfectly... rawk.
> >
> > Thanks,
> > Brandon
> >
> > On 2/17/07, *Brandon Goodin* <brandon.goodin@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > This is very interesting and I'd like to know more about why this
> > number is important apart from other things like a
> > major.minor.revision.timestamp format. I'm not really picking up
> > the importance from the previous comments. Here is my
> > understanding, help me to clear the fog out... The serial is used
> > to identify a unique build. This unique build is important for
> > tracing back to what? If we do not have an anchor in our source
> > code repository to compare it to what good does it do us?
> >
> > Brandon
> >
> >
> > On 2/17/07, *Clinton Begin* < clinton.begin@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> >
> > Paul,
> >
> > I disagree entirely.
> >
> > Open any product on your PC today, Java IDE, Visual
> > Studio...anything. It will have a build number. Not just
> > software really, any and every product on the planet has a
> > serial number. They are useful for uniquely identifying
> > something. The major.minor.bug release version is very
> > subjective and we tend to manipulate it that way. The build
> > number is automated and therefore more reliable as a unique ID
> > for the software version.
> >
> > I agree about the disconnect with SVN in the past. What we
> > typically do on commercial projects is have the CI server
> > automatically create a tag for the build in SVN. That solves
> > the disconnect issue. iBATIS hasn't had a CI server until
> > recently, so the tagging was manual. Now we do have a CI
> > server and can automate the relationship one way or another
> > (either tag SVN with the build number or pul the rev number
> > from SVN and tag the build with that).
> >
> > It's important to me and easy to produce. So regardless of
> > what build system we use, I'd like to ensure that a build
> > number is represented on the deployable ZIP filename, the JAR
> > file names the manifest file and the release.txt.
> >
> > Clinton
> >
> >
> >
> > On 2/17/07, *Paul Benedict* < pbenedict@apache.org
> > <ma...@apache.org>> wrote:
> >
> > 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
> > <ma...@gmail.com>
> > > <mailto:jeffgbutler@gmail.com
> > <ma...@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
> > <ma...@apache.org>
> > > <mailto: lmeadors@apache.org
> > <ma...@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
> > >
> > >
> > >
> >
> >
> >
> >
>
>
Re: iBATIS for Java 2.3.0 General Availability
Posted by Larry Meadors <lm...@apache.org>.
On 2/17/07, Paul Benedict <pb...@apache.org> wrote:
> I understand the argument, but I am not aware of any other project at
> Apache that includes a build number as part of their version number.
> That doesn't mean you're the only one, but I think it's a minority
> practice. And if it is a minority practice, there must be a good reason
> to not do it on a general basis.
Not necessarily - a lot of people use EJB, is that a good reason for
me to use it?
Consensus != best practice.
Honestly, I don't give a dang how others do it, or if how we do it is
popular. I care that it adds value. In my opinion, adding the svn
revision that was used to create the release does that.
> My point is the Build number is irrelevant to the release. If you
> produce snapshots until an official build, then you've eliminated the
> need for it. I never needed it, and I think eliminating it may ease
> releases. What you're essentially doing is using the build number as THE
> revision number. However, the revision doesn't need a promotion until
> you're ready to vote on a release. So given three releasable versions
> using your Build scheme (2.4.000, 2.4.256, 2.4.667), that's nothing
> really more than 2.4.0, 2.4.1, and 2.4.2.
If you just use an arbitrary number, yes. 1,2,3 and 121, 256, 327 are
equally useful or useless depending on your outlook. If the glass half
full or half empty? :-)
On the other hand, doing it with the SVN revision adds the same sort
of information as the either type of numbering, but also provides the
benefit of giving our users an easy way to see exactly what the
changes are between snapshots or real releases.
So, it sounds like other than some philosophical musings on the
deterministic duality of release numbers, everyone is OK if I use SVN
revision for that number.
Cool, I'll try to get that working.
Larry
Re: iBATIS for Java 2.3.0 General Availability
Posted by Paul Benedict <pb...@apache.org>.
Clinton,
I understand the argument, but I am not aware of any other project at
Apache that includes a build number as part of their version number.
That doesn't mean you're the only one, but I think it's a minority
practice. And if it is a minority practice, there must be a good reason
to not do it on a general basis.
My point is the Build number is irrelevant to the release. If you
produce snapshots until an official build, then you've eliminated the
need for it. I never needed it, and I think eliminating it may ease
releases. What you're essentially doing is using the build number as THE
revision number. However, the revision doesn't need a promotion until
you're ready to vote on a release. So given three releasable versions
using your Build scheme (2.4.000, 2.4.256, 2.4.667), that's nothing
really more than 2.4.0, 2.4.1, and 2.4.2.
Paul
Brandon Goodin wrote:
> I talked to larry and he floated his idea on this. My main thought
> about the build number was that it has to tie meaningfully back to the
> source state. Larry's idea does that perfectly... rawk.
>
> Thanks,
> Brandon
>
> On 2/17/07, *Brandon Goodin* <brandon.goodin@gmail.com
> <ma...@gmail.com>> wrote:
>
> This is very interesting and I'd like to know more about why this
> number is important apart from other things like a
> major.minor.revision.timestamp format. I'm not really picking up
> the importance from the previous comments. Here is my
> understanding, help me to clear the fog out... The serial is used
> to identify a unique build. This unique build is important for
> tracing back to what? If we do not have an anchor in our source
> code repository to compare it to what good does it do us?
>
> Brandon
>
>
> On 2/17/07, *Clinton Begin* < clinton.begin@gmail.com
> <ma...@gmail.com>> wrote:
>
>
> Paul,
>
> I disagree entirely.
>
> Open any product on your PC today, Java IDE, Visual
> Studio...anything. It will have a build number. Not just
> software really, any and every product on the planet has a
> serial number. They are useful for uniquely identifying
> something. The major.minor.bug release version is very
> subjective and we tend to manipulate it that way. The build
> number is automated and therefore more reliable as a unique ID
> for the software version.
>
> I agree about the disconnect with SVN in the past. What we
> typically do on commercial projects is have the CI server
> automatically create a tag for the build in SVN. That solves
> the disconnect issue. iBATIS hasn't had a CI server until
> recently, so the tagging was manual. Now we do have a CI
> server and can automate the relationship one way or another
> (either tag SVN with the build number or pul the rev number
> from SVN and tag the build with that).
>
> It's important to me and easy to produce. So regardless of
> what build system we use, I'd like to ensure that a build
> number is represented on the deployable ZIP filename, the JAR
> file names the manifest file and the release.txt.
>
> Clinton
>
>
>
> On 2/17/07, *Paul Benedict* < pbenedict@apache.org
> <ma...@apache.org>> wrote:
>
> 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
> <ma...@gmail.com>
> > <mailto:jeffgbutler@gmail.com
> <ma...@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
> <ma...@apache.org>
> > <mailto: lmeadors@apache.org
> <ma...@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
> >
> >
> >
>
>
>
>
Re: iBATIS for Java 2.3.0 General Availability
Posted by Clinton Begin <cl...@gmail.com>.
Yes, I agree. We can either tag it with the arbitrary build number (what
most projects do), or pull the rev number from SVN (almost impossible to
fake).
The reason most projects go with the tag approach is that it keeps a running
history of all successful builds that you can then just pluck out and
release from. For example, build #12344 is sent through Q/A testing, broad
integration testing and the feature set is run past the user. If all is
acceptable, build #12344 is released as 2.3.1, which are numbers that are
incremented based on whether the build included a majority of new features,
or just simple bug fixes....or more rarely...a major release.
So to answer your question from before, the build number precedes the
subjective, man-made version number.
Clinton
On 2/17/07, Brandon Goodin <br...@gmail.com> wrote:
>
> I talked to larry and he floated his idea on this. My main thought about
> the build number was that it has to tie meaningfully back to the source
> state. Larry's idea does that perfectly... rawk.
>
> Thanks,
> Brandon
>
> On 2/17/07, Brandon Goodin <br...@gmail.com> wrote:
> >
> > This is very interesting and I'd like to know more about why this number
> > is important apart from other things like a
> > major.minor.revision.timestamp format. I'm not really picking up the
> > importance from the previous comments. Here is my understanding, help me to
> > clear the fog out... The serial is used to identify a unique build. This
> > unique build is important for tracing back to what? If we do not have an
> > anchor in our source code repository to compare it to what good does it do
> > us?
> >
> > Brandon
> >
> > On 2/17/07, Clinton Begin < clinton.begin@gmail.com> wrote:
> > >
> > >
> > > Paul,
> > >
> > > I disagree entirely.
> > >
> > > Open any product on your PC today, Java IDE, Visual
> > > Studio...anything. It will have a build number. Not just software really,
> > > any and every product on the planet has a serial number. They are useful
> > > for uniquely identifying something. The major.minor.bug release
> > > version is very subjective and we tend to manipulate it that way. The build
> > > number is automated and therefore more reliable as a unique ID for the
> > > software version.
> > >
> > > I agree about the disconnect with SVN in the past. What we typically
> > > do on commercial projects is have the CI server automatically create a tag
> > > for the build in SVN. That solves the disconnect issue. iBATIS hasn't had a
> > > CI server until recently, so the tagging was manual. Now we do have a CI
> > > server and can automate the relationship one way or another (either tag SVN
> > > with the build number or pul the rev number from SVN and tag the build with
> > > that).
> > >
> > > It's important to me and easy to produce. So regardless of what build
> > > system we use, I'd like to ensure that a build number is represented on the
> > > deployable ZIP filename, the JAR file names the manifest file and the
> > > release.txt.
> > >
> > > Clinton
> > >
> > >
> > > On 2/17/07, Paul Benedict < pbenedict@apache.org> wrote:
> > > >
> > > > 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
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
Re: iBATIS for Java 2.3.0 General Availability
Posted by Brandon Goodin <br...@gmail.com>.
I talked to larry and he floated his idea on this. My main thought about the
build number was that it has to tie meaningfully back to the source state.
Larry's idea does that perfectly... rawk.
Thanks,
Brandon
On 2/17/07, Brandon Goodin <br...@gmail.com> wrote:
>
> This is very interesting and I'd like to know more about why this number
> is important apart from other things like a major.minor.revision.timestampformat. I'm not really picking up the importance from the previous comments.
> Here is my understanding, help me to clear the fog out... The serial is used
> to identify a unique build. This unique build is important for tracing back
> to what? If we do not have an anchor in our source code repository to
> compare it to what good does it do us?
>
> Brandon
>
> On 2/17/07, Clinton Begin <cl...@gmail.com> wrote:
> >
> >
> > Paul,
> >
> > I disagree entirely.
> >
> > Open any product on your PC today, Java IDE, Visual Studio...anything.
> > It will have a build number. Not just software really, any and every
> > product on the planet has a serial number. They are useful for uniquely
> > identifying something. The major.minor.bug release version is very
> > subjective and we tend to manipulate it that way. The build number is
> > automated and therefore more reliable as a unique ID for the software
> > version.
> >
> > I agree about the disconnect with SVN in the past. What we typically do
> > on commercial projects is have the CI server automatically create a tag for
> > the build in SVN. That solves the disconnect issue. iBATIS hasn't had a CI
> > server until recently, so the tagging was manual. Now we do have a CI
> > server and can automate the relationship one way or another (either tag SVN
> > with the build number or pul the rev number from SVN and tag the build with
> > that).
> >
> > It's important to me and easy to produce. So regardless of what build
> > system we use, I'd like to ensure that a build number is represented on the
> > deployable ZIP filename, the JAR file names the manifest file and the
> > release.txt.
> >
> > Clinton
> >
> >
> > On 2/17/07, Paul Benedict < pbenedict@apache.org> wrote:
> > >
> > > 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
> > > >
> > > >
> > > >
> > >
> >
> >
>
Re: iBATIS for Java 2.3.0 General Availability
Posted by Brandon Goodin <br...@gmail.com>.
This is very interesting and I'd like to know more about why this number is
important apart from other things like a
major.minor.revision.timestampformat. I'm not really picking up the
importance from the previous comments.
Here is my understanding, help me to clear the fog out... The serial is used
to identify a unique build. This unique build is important for tracing back
to what? If we do not have an anchor in our source code repository to
compare it to what good does it do us?
Brandon
On 2/17/07, Clinton Begin <cl...@gmail.com> wrote:
>
>
> Paul,
>
> I disagree entirely.
>
> Open any product on your PC today, Java IDE, Visual Studio...anything. It
> will have a build number. Not just software really, any and every product
> on the planet has a serial number. They are useful for uniquely identifying
> something. The major.minor.bug release version is very subjective and we
> tend to manipulate it that way. The build number is automated and therefore
> more reliable as a unique ID for the software version.
>
> I agree about the disconnect with SVN in the past. What we typically do
> on commercial projects is have the CI server automatically create a tag for
> the build in SVN. That solves the disconnect issue. iBATIS hasn't had a CI
> server until recently, so the tagging was manual. Now we do have a CI
> server and can automate the relationship one way or another (either tag SVN
> with the build number or pul the rev number from SVN and tag the build with
> that).
>
> It's important to me and easy to produce. So regardless of what build
> system we use, I'd like to ensure that a build number is represented on the
> deployable ZIP filename, the JAR file names the manifest file and the
> release.txt.
>
> Clinton
>
>
> On 2/17/07, Paul Benedict <pb...@apache.org> wrote:
> >
> > 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
> > > <ma...@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
> > >
> > >
> > >
> >
>
>
Re: iBATIS for Java 2.3.0 General Availability
Posted by Clinton Begin <cl...@gmail.com>.
Paul,
I disagree entirely.
Open any product on your PC today, Java IDE, Visual Studio...anything. It
will have a build number. Not just software really, any and every product
on the planet has a serial number. They are useful for uniquely identifying
something. The major.minor.bug release version is very subjective and we
tend to manipulate it that way. The build number is automated and therefore
more reliable as a unique ID for the software version.
I agree about the disconnect with SVN in the past. What we typically do on
commercial projects is have the CI server automatically create a tag for the
build in SVN. That solves the disconnect issue. iBATIS hasn't had a CI
server until recently, so the tagging was manual. Now we do have a CI
server and can automate the relationship one way or another (either tag SVN
with the build number or pul the rev number from SVN and tag the build with
that).
It's important to me and easy to produce. So regardless of what build
system we use, I'd like to ensure that a build number is represented on the
deployable ZIP filename, the JAR file names the manifest file and the
release.txt.
Clinton
On 2/17/07, Paul Benedict <pb...@apache.org> wrote:
>
> 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
> > <ma...@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
> > <ma...@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
> >
> >
> >
>
Re: iBATIS for Java 2.3.0 General Availability
Posted by Paul Benedict <pb...@apache.org>.
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
> <ma...@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
> <ma...@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
>
>
>
Re: iBATIS for Java 2.3.0 General Availability
Posted by Paul Benedict <pb...@apache.org>.
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
> <ma...@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
> <ma...@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
>
>
>
Re: [JDBC type = ARRAY / Java type = ?] iBATIS for Java 2.3.0 General Availability
Posted by Clinton Begin <cl...@gmail.com>.
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 <je...@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 <lm...@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
> >
> >
> >
Re: [JDBC type = ARRAY / Java type = ?] iBATIS for Java 2.3.0 General Availability
Posted by Jeff Butler <je...@gmail.com>.
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 <lm...@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
>
>
>
Re: [JDBC type = ARRAY / Java type = ?] iBATIS for Java 2.3.0 General Availability
Posted by Larry Meadors <lm...@apache.org>.
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
On 2/15/07, Brandon Goodin <br...@gmail.com> wrote:
> I think it's a good idea if we all take a turn at the release. I'll work
> close with Larry to get my feet wet with the process and prepare to take a
> turn at some point.
>
> Brandon
>
>
> On 2/15/07, Jeff Butler <je...@gmail.com> wrote:
> >
> > This page is a good checklist for the process:
> >
> > http://jakarta.apache.org/commons/releases/release.html
> >
> > You'll also need to get yourself a PGP key and add it to a public registry
> (pretty easy).
> >
> > Good luck! I'm happy to help if you get stuck.
> >
> > Jeff Butler
> >
> >
> > On 2/15/07, Larry Meadors < lmeadors@apache.org> wrote:
> >
> > > I'll raise my hand as the guinea pig^W^W pioneer to do the next
> > > release as an experimental maven build.
> > >
> > > If Jeff can help me with the process requirements, I can pester
> > > Brandon and others for maven support.
> > >
> > > Larry
> > >
> > >
> > > On 2/15/07, Jeff Butler < jeffgbutler@gmail.com > wrote:
> > > > We are currently discussing the idea of moving to Maven for our build
> > > > process (see the dev list archives). Once we decide about that, it
> will be
> > > > easier to decide if/when we will get the Jars to ibiblio.
> > > >
> > > > For now, I doubt that 2.3.0 will make it to ibiblio. But the next
> release
> > > > of iBATIS might.
> > > >
> > > > Jeff Butler
> > > >
> > > >
> > > >
> > > > On 2/15/07, bkbonner < brian.bonner@paraware.com> wrote:
> > > > >
> > > > > Jeff, are there any plans to have the updated version published to
> > > > Ibiblio?
> > > > > (specifically maven2?) Thanks!
> > > > >
> > > > > Brian
> > > > >
> > > > >
> > > > > Jeff Butler-2 wrote:
> > > > > >
> > > > > > The votes are in an iBATIS for Java version 2.3.0 is declared to
> be
> > > > Apache
> > > > > > general availability status.
> > > > > >
> > > > > > This release is the first release that does not include the DAO
> > > > framework.
> > > > > > The DAO framework is available as a separate download on the Java
> > > > > > downloads
> > > > > > page, but we recommend migrating to Spring framework based DAOs.
> > > > > >
> > > > > > The official announcement will be reflected on the website within
> the
> > > > next
> > > > > > hour, and you can download it from
> > > > > > http://ibatis.apache.org/javadownloads.cgi.
> > > > > >
> > > > > > If you've been using 2.3.0 already, there's no need to download it
> again
> > > > -
> > > > > > it is the same JAR.
> > > > > >
> > > > > > Enjoy!
> > > > > > Jeff Butler
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > View this message in context:
> > > >
> http://www.nabble.com/iBATIS-for-Java-2.3.0-General-Availability-tf3210955.html#a8995718
> > > > > Sent from the iBATIS - User - Java mailing list archive at
> Nabble.com.
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
>
Re: [JDBC type = ARRAY / Java type = ?] iBATIS for Java 2.3.0 General Availability
Posted by Brandon Goodin <br...@gmail.com>.
I think it's a good idea if we all take a turn at the release. I'll work
close with Larry to get my feet wet with the process and prepare to take a
turn at some point.
Brandon
On 2/15/07, Jeff Butler <je...@gmail.com> wrote:
>
> This page is a good checklist for the process:
>
> http://jakarta.apache.org/commons/releases/release.html
>
> You'll also need to get yourself a PGP key and add it to a public registry
> (pretty easy).
>
> Good luck! I'm happy to help if you get stuck.
>
> Jeff Butler
>
>
> On 2/15/07, Larry Meadors <lm...@apache.org> wrote:
> >
> > I'll raise my hand as the guinea pig^W^W pioneer to do the next
> > release as an experimental maven build.
> >
> > If Jeff can help me with the process requirements, I can pester
> > Brandon and others for maven support.
> >
> > Larry
> >
> >
> > On 2/15/07, Jeff Butler <jeffgbutler@gmail.com > wrote:
> > > We are currently discussing the idea of moving to Maven for our build
> > > process (see the dev list archives). Once we decide about that, it
> > will be
> > > easier to decide if/when we will get the Jars to ibiblio.
> > >
> > > For now, I doubt that 2.3.0 will make it to ibiblio. But the next
> > release
> > > of iBATIS might.
> > >
> > > Jeff Butler
> > >
> > >
> > >
> > > On 2/15/07, bkbonner < brian.bonner@paraware.com> wrote:
> > > >
> > > > Jeff, are there any plans to have the updated version published to
> > > Ibiblio?
> > > > (specifically maven2?) Thanks!
> > > >
> > > > Brian
> > > >
> > > >
> > > > Jeff Butler-2 wrote:
> > > > >
> > > > > The votes are in an iBATIS for Java version 2.3.0 is declared to
> > be
> > > Apache
> > > > > general availability status.
> > > > >
> > > > > This release is the first release that does not include the DAO
> > > framework.
> > > > > The DAO framework is available as a separate download on the Java
> > > > > downloads
> > > > > page, but we recommend migrating to Spring framework based DAOs.
> > > > >
> > > > > The official announcement will be reflected on the website within
> > the
> > > next
> > > > > hour, and you can download it from
> > > > > http://ibatis.apache.org/javadownloads.cgi.
> > > > >
> > > > > If you've been using 2.3.0 already, there's no need to download it
> > again
> > > -
> > > > > it is the same JAR.
> > > > >
> > > > > Enjoy!
> > > > > Jeff Butler
> > > > >
> > > > >
> > > >
> > > > --
> > > > View this message in context:
> > >
> > http://www.nabble.com/iBATIS-for-Java-2.3.0-General-Availability-tf3210955.html#a8995718
> > > > Sent from the iBATIS - User - Java mailing list archive at
> > Nabble.com.
> > > >
> > > >
> > >
> > >
> >
>
>
Re: [JDBC type = ARRAY / Java type = ?] iBATIS for Java 2.3.0 General Availability
Posted by Jeff Butler <je...@gmail.com>.
This page is a good checklist for the process:
http://jakarta.apache.org/commons/releases/release.html
You'll also need to get yourself a PGP key and add it to a public registry
(pretty easy).
Good luck! I'm happy to help if you get stuck.
Jeff Butler
On 2/15/07, Larry Meadors <lm...@apache.org> wrote:
>
> I'll raise my hand as the guinea pig^W^W pioneer to do the next
> release as an experimental maven build.
>
> If Jeff can help me with the process requirements, I can pester
> Brandon and others for maven support.
>
> Larry
>
>
> On 2/15/07, Jeff Butler <je...@gmail.com> wrote:
> > We are currently discussing the idea of moving to Maven for our build
> > process (see the dev list archives). Once we decide about that, it will
> be
> > easier to decide if/when we will get the Jars to ibiblio.
> >
> > For now, I doubt that 2.3.0 will make it to ibiblio. But the next
> release
> > of iBATIS might.
> >
> > Jeff Butler
> >
> >
> >
> > On 2/15/07, bkbonner <br...@paraware.com> wrote:
> > >
> > > Jeff, are there any plans to have the updated version published to
> > Ibiblio?
> > > (specifically maven2?) Thanks!
> > >
> > > Brian
> > >
> > >
> > > Jeff Butler-2 wrote:
> > > >
> > > > The votes are in an iBATIS for Java version 2.3.0 is declared to be
> > Apache
> > > > general availability status.
> > > >
> > > > This release is the first release that does not include the DAO
> > framework.
> > > > The DAO framework is available as a separate download on the Java
> > > > downloads
> > > > page, but we recommend migrating to Spring framework based DAOs.
> > > >
> > > > The official announcement will be reflected on the website within
> the
> > next
> > > > hour, and you can download it from
> > > > http://ibatis.apache.org/javadownloads.cgi.
> > > >
> > > > If you've been using 2.3.0 already, there's no need to download it
> again
> > -
> > > > it is the same JAR.
> > > >
> > > > Enjoy!
> > > > Jeff Butler
> > > >
> > > >
> > >
> > > --
> > > View this message in context:
> >
> http://www.nabble.com/iBATIS-for-Java-2.3.0-General-Availability-tf3210955.html#a8995718
> > > Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
> > >
> > >
> >
> >
>
Re: [JDBC type = ARRAY / Java type = ?] iBATIS for Java 2.3.0 General Availability
Posted by Larry Meadors <lm...@apache.org>.
I'll raise my hand as the guinea pig^W^W pioneer to do the next
release as an experimental maven build.
If Jeff can help me with the process requirements, I can pester
Brandon and others for maven support.
Larry
On 2/15/07, Jeff Butler <je...@gmail.com> wrote:
> We are currently discussing the idea of moving to Maven for our build
> process (see the dev list archives). Once we decide about that, it will be
> easier to decide if/when we will get the Jars to ibiblio.
>
> For now, I doubt that 2.3.0 will make it to ibiblio. But the next release
> of iBATIS might.
>
> Jeff Butler
>
>
>
> On 2/15/07, bkbonner <br...@paraware.com> wrote:
> >
> > Jeff, are there any plans to have the updated version published to
> Ibiblio?
> > (specifically maven2?) Thanks!
> >
> > Brian
> >
> >
> > Jeff Butler-2 wrote:
> > >
> > > The votes are in an iBATIS for Java version 2.3.0 is declared to be
> Apache
> > > general availability status.
> > >
> > > This release is the first release that does not include the DAO
> framework.
> > > The DAO framework is available as a separate download on the Java
> > > downloads
> > > page, but we recommend migrating to Spring framework based DAOs.
> > >
> > > The official announcement will be reflected on the website within the
> next
> > > hour, and you can download it from
> > > http://ibatis.apache.org/javadownloads.cgi.
> > >
> > > If you've been using 2.3.0 already, there's no need to download it again
> -
> > > it is the same JAR.
> > >
> > > Enjoy!
> > > Jeff Butler
> > >
> > >
> >
> > --
> > View this message in context:
> http://www.nabble.com/iBATIS-for-Java-2.3.0-General-Availability-tf3210955.html#a8995718
> > Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
> >
> >
>
>
Re: [JDBC type = ARRAY / Java type = ?] iBATIS for Java 2.3.0 General Availability
Posted by Jeff Butler <je...@gmail.com>.
We are currently discussing the idea of moving to Maven for our build
process (see the dev list archives). Once we decide about that, it will be
easier to decide if/when we will get the Jars to ibiblio.
For now, I doubt that 2.3.0 will make it to ibiblio. But the next release
of iBATIS might.
Jeff Butler
On 2/15/07, bkbonner <br...@paraware.com> wrote:
>
>
> Jeff, are there any plans to have the updated version published to
> Ibiblio?
> (specifically maven2?) Thanks!
>
> Brian
>
>
> Jeff Butler-2 wrote:
> >
> > The votes are in an iBATIS for Java version 2.3.0 is declared to be
> Apache
> > general availability status.
> >
> > This release is the first release that does not include the DAO
> framework.
> > The DAO framework is available as a separate download on the Java
> > downloads
> > page, but we recommend migrating to Spring framework based DAOs.
> >
> > The official announcement will be reflected on the website within the
> next
> > hour, and you can download it from
> > http://ibatis.apache.org/javadownloads.cgi.
> >
> > If you've been using 2.3.0 already, there's no need to download it again
> -
> > it is the same JAR.
> >
> > Enjoy!
> > Jeff Butler
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/iBATIS-for-Java-2.3.0-General-Availability-tf3210955.html#a8995718
> Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
>
>
Re: [JDBC type = ARRAY / Java type = ?] iBATIS for Java 2.3.0
General Availability
Posted by bkbonner <br...@paraware.com>.
Jeff, are there any plans to have the updated version published to Ibiblio?
(specifically maven2?) Thanks!
Brian
Jeff Butler-2 wrote:
>
> The votes are in an iBATIS for Java version 2.3.0 is declared to be Apache
> general availability status.
>
> This release is the first release that does not include the DAO framework.
> The DAO framework is available as a separate download on the Java
> downloads
> page, but we recommend migrating to Spring framework based DAOs.
>
> The official announcement will be reflected on the website within the next
> hour, and you can download it from
> http://ibatis.apache.org/javadownloads.cgi.
>
> If you've been using 2.3.0 already, there's no need to download it again -
> it is the same JAR.
>
> Enjoy!
> Jeff Butler
>
>
--
View this message in context: http://www.nabble.com/iBATIS-for-Java-2.3.0-General-Availability-tf3210955.html#a8995718
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.