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


Reply via email to