Robert Zeigler wrote:
Yes and no.
On the one hand, it's nice for each sub-project to have its own
release lifecycle, etc.
On the other hand, it makes it really easy to know what is compatible
with what.
Consider a scenario like:
tapestry-core 5.0.14 requires:
tapestry-ioc 5.0.7
tapestry-annotations 5.0.3
Since it's a hibernate-based app, we'll be using:
tapestry-hibernate 5.0.9
Hm... what are the dependencies of tapestry-hibernate 5.0.9? Is it on
tapestry-core 5.0.9? Or later? Or 5.0.14? Or...?
Keeping the version numbers and the releases in-sync makes it easier
for a person to wrap his/her head around what goes with what.
Robert
i do like the (theoretical) increase in agility from
release-per-subproject. i also concede that a big-thump release is
simpler. however, isn't the intent of Maven to make just these kinds of
dependencies trivial to manage? i think the more important
question--rather than is it manageable--is: is it needed?
one thought would be to review "release-readiness" for each subproject
on an on-going basis. meaning, for each subproject make note of when
that subproject is ready for another release relative to the time to
next release of the whole project. it should be straight forward to
determine if the agility gained by releasing subprojects independently
is worth the added work of configuring the Maven builds to manage
subprojects.
thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
