LOL. Just saw this on DZone.
http://escx.blogspot.com/2007/02/hating-maven-less-than-ant.html To be honest it scared me more about Maven 2, but the author still supports it. Clinton On 2/17/07, Slava Imeshev <[EMAIL PROTECTED]> wrote:
In build management the generally accepted (or those to be considered OK) practices are: 1. Use adding a build number to product packages that are intermediate in nature, such as developer or nightly builds. The main advantage is that this allows quickly identifying the state of the code base at the moment of the build. Some also add a change list number if a version control system supports it. If the version control system doesn't support change lists, a version control time stamp may be used instead. There is no general best practice on the format, but most follow the scheme below.This naming scheme communicates well the temporarily/snapshot nature of the package.: <product-name>-<major>.<minor>.<patch>-<build number>-<change-list-number> The ultimate naming for iBATIS here would be ibatis-2.3.0-345-10685.jar 2. Use <product-name>-<major>.<minor>.<patch> for released product packages. This simplifies management of third-party dependencies for users, communication with support e.t.c For a product it also allows for easy branding. Usually, the build number and the change number are not required in the package names because these a values always documented through the release process. The ultimate naming for iBATIS here would be ibatis-2.3.1.jar In either case the build number and the change number are often included into the product packaging, release information on product web sites, release notes and "About" information. These are a couple of practices we, as a software build management company, recommend to our customers. They proved to work well over the years. Note that there is a case when using scheme number 1 is acceptable for released products when releases are small, often, with no intermediate releases, and a build system doesn't support automated management of a version number. The only example I can think of is Linux's package names. Just my two cents. Regards, Slava Imeshev [EMAIL PROTECTED] www.viewtier.com ----- Original Message ----- From: "Paul Benedict" <[EMAIL PROTECTED]> To: <dev@ibatis.apache.org> Sent: Saturday, February 17, 2007 2:47 PM Subject: Re: iBATIS for Java 2.3.0 General Availability > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
