Interesting scenario but I don't like your conclusion. We want to get away from forcing a releaase of all three at the same time. That was a major goal of the maven reorg. We need to try to solve this problem without always release all three.
Sean On 2/17/06, Manfred Geiler <[EMAIL PROTECTED]> wrote: > And that's why I still have the opinion that we cannot do other than > release all three at the same time. > > Scenario: > > 1. We release commons-1.1.2 + core 1.1.2 (core 1.1.2 depends on commons-1.1.2) > 2. days go by... > 3. We release commons-1.1.3 (because there where significant changes) > + tomahawk 1.1.3 (which depends on commons-1.1.3) > > So, there are now the following official releases out there: > > commons-1.1.2 > commons-1.1.3 > core-1.1.2 > tomahawk-1.1.3 > > User "happy" starts his brandnew Maven project "unlucky", decides to > use the latest stable releases of everything and defines the following > dependencies: > > XY depends on myfaces-api 1.1.2 (scope compile) > XY depends on myfaces-impl 1.1.2 (scope runtime) > XY depends on tomahawk 1.1.3 (scope compile) > > Now he builds the WAR. Guess what he ends up with? > WEB-INF/lib/myfaces-api-1.1.2.jar > WEB-INF/lib/myfaces-commons-1.1.2.jar > WEB-INF/lib/myfaces-commons-1.1.3.jar > WEB-INF/lib/myfaces-impl-1.1.2.jar > WEB-INF/lib/myfaces-tomahawk-1.1.3.jar > > Not good! > > Ergo: We must release all 3 modules in sync. > > Manfred > > > > > > > On 2/17/06, Manfred Geiler <[EMAIL PROTECTED]> wrote: > > > And at some future point, we'll probably also incorporate a > > > "repackaging" step into one of these (I'd suggest core, probably) to > > > give the two commons versions different namespaces. > > > > That's what I'm attracted at more and more, too. ;-) > > > > Manfred > > >
