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* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> 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* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> 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* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> 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* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
> > <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>>> wrote:
> >
> > I agree that the build number is useless. Apache
> policy says that
> > there are not different versions of a
release. So we
> really
> > shouldn't have 2.3.0-638 and 2.3.0-677, we
only have
> one 2.3.0
> > release (we've only broken that rule one time
that I
> remember).
> >
> > I kind of like the way Derby does it. The
download
> is just
> > Derby10.2.2.0, and they add the SVN revision
number
> in the manifest
> > Bundle-Version property (e.g.
> 10.2.2000000.485682). I haven't
> > looked at their build to see how they get the SVN
> number into the
> > manifest - hopefully it's not a manual hack.
> >
> > I'd like to keep the version number on the name of
> the JAR file like
> > we're doing now (ibatis-2.3.0.jar) - just lose the
> build number.
> >
> > Jeff Butler
> >
> > On 2/17/07, *Larry Meadors* <
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
> > <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>>> wrote:
> >
> > OK, as I am digging through this, I see
that we
> have this "build
> > number" thing on the download.
> >
> > I am wondering if we should change it to make
> that number have
> > some more value.
> >
> > What I mean is: "What does '
> ibatis-2.3.0.677.zip' really tell me
> > about
> > the build?"
> >
> > 677 is just an arbitrary magic number
tagged onto
> the build.
> >
> > Should we use something like the SVN release
> number instead?
> > That way,
> > I can very easily look to see *exactly*
what has
> changed between
> > releases by doing this:
> >
> > svn diff old:new
> >
> > That seems a lot more useful than 638 or 677.
> >
> > Thoughts? I am going to do the next
release that
> way instead
> > unless I
> > hear wailing and gnashing of teeth.
> >
> > Larry
> >
> >
> >
>
>
>
>
