Hi Felix
I had a look at felix to see if I could work out how you do the
independent releases. I didn't look through absolutely everything but
I only found two modules that had sub-modules (gogo and http). Of those
two it looks as though the pom structure in gogo might be similar
to what we need in Aries. Is this a model you would recommend? Or is
there something closer?
Zoe
Hi,
Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
Wouldn't that imply that each bundle has its own lifecycle ?
I think a while ago we agreed on having one release per "component",
i.e. blueprint (which includes api + core + cm + ...).
I'm not sure how well this would go if we have blueprint-core
0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
I bet you won't release blueprint-api as version 0.4.0 if it is the same
as 0.3.0, right ?
Regards
Felix
> From a users point of view, it certainly does not help because all the
maven transitive dependencies are kinda screwed.
On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<[email protected]> wrote:
Hi,
Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
(c) Where an Aries module depends on other Aries modules, it will depend
on the released versions of the other modules _until_ it requires a
change in the module that it depends on, at which stage it will switch
to a dependency on the development version.
So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3, proxy
0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs to
pick up a change in proxy the blueprint top level pom will need to be
modified to point to proxy 0.4-SNAPSHOT.
I would assume this means "depends on modified API" and does not mean
"depends on some bug fixed in the implementation", right ?
If you're referring to the semantic meaning attached to moving from
0.3 to 0.4 then I think that would be taking this discussion in a
different direction. But that is a good point. Before getting into a
semantic versioning discussion, I think the intent of this was to so
if there are broken tests in 0.4-SNAPSHOT of a module which are fixed
by pulling in 0.4-SNAPSHOT of its dependency then its dependency
should be updated.
No, this is not about semantic versioning (yet).
This is about the following: Consider bundle X depends on the API
org.apache.aries.y.api of bundle Y. Now some implementation of this API
in package org.apache.aries.y.impl of bundle Y has a bug which must be
fixed. In this case the dependency of bundle X on Y should not be
changed.
Regards
Felix
Regards
Felix
This will lead us towards being able to release by module but it implies
a change in development practice. I will make the pom changes locally
and test them but I'd like to check that release-by-module is still the
goal and that you all think this is a reasonable way to be able to
achieve it.
Zoë