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ë > >> > >> > >> > > > > > >
