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