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