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]
