We've had the opposite experience with our large scale implementation. We keep the release numbers in sync by only setting it in the Parent POM so regardless of number of modules there is only one change to be made.
The purist in me want to version everything separately but it has proved to be more practical to keep them in sync, making it obvious, even to the customer!, that they all go together. ________________________________ Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time, 600 times a day -----Original Message----- From: Ron Wheeler [mailto:[email protected]] Sent: Friday, November 05, 2010 12:35 PM To: [email protected] Subject: Re: module versioning best practice We had to deal with this on a large scale and after a few attempts decided that the least painful solution was to treat our own libraries almost like third part software. If a library does not need to be changed, it is not changed and the software that depends on it just uses the right number Version 1.1 of module A depending on version 1.0 of module B is acceptable. We maintain a compatibility list for each "Release" of the application that details the right release of each of the subcomponents. We tried keeping the release numbers in synch but it was too much work for nothing to release 60 modules when only 5 actually changed. It is much easier to look up the spreadsheet to see what components make up "release" x.y.z of the application. We use aggregation POMs to simplify the maintenance of releases as well. This may not be as helpful when you have long release cycles but we are in production (3 years now) and we are releasing as often as once a week for small changes, bug fixes or minor enhancements and just did not have the resources to do the housekeeping with 60 projects. I hope that this helps. Ron On 05/11/2010 8:31 AM, Dirk Reske wrote: > Hello, > > I have question about best practices for the versioning of my modules. > Simple example: > > I have my "main" project: MainProject (just a simple webapp) and a > bunch of separate maintained modules, e.g. > > external.api > |--messaging.api > |--sms.impl > |--email.impl > > The messaging api contains a set of interfaces for external messaging > services and the sms.impl and email.impl contains concrete > implementations therefore. > How should I set the version number of these sub modules? Should each > has its own or should they derive from the external.api super-pom? > My main project has all three as depedency. > I think I can get version conflicts with both methods. If I change the > messaging api, and increment the versions of all modules, but only > change the version of the messaging.api dependency in the main > project, I have a current messaging.api but older sms.impl that does > not use the current interfaces. > > Thanks > Dirk > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
