if the release cycle is indeed only 2-3 months for major releases, then
i would have to agree that my previous comment is invalid--i would keep
it as one complete project released-at-once. for such a large body of
code it is hard to be much more agile than 2 months.
that said they may be uses for subproject dev release. but that still
seems of little benefit given the SNAPSHOT feature of maven.
Howard Lewis Ship wrote:
Exactly; Hibernate has made this mistake and it's impossible to tell
what versions go with what. Ditto for Maven.
I'd rather we have a process where we can come out with a 5.1, 5.2,
5.3 release every few months. That's my vision, anyway, add a couple
of significant features, work towards a GA release, lather rinse
repeat.
On Mon, Jul 14, 2008 at 12:00 PM, Robert Zeigler <[EMAIL PROTECTED]> 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
On Jul 14, 2008, at 7/141:19 PM , Andreas Andreou wrote:
Wouldn't it make sense to consider subprojects having different lifecycle
that
the master project?
So that you could have a release as soon as a major issue in that
specific project
is fixed - instead of having to do a global release and update version
numbers of
everything else?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
