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]>> 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]>> 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]>> 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]>>> 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]>>> 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
>
>
>
