aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <>
Subject Re: svn commit: r1203307 - in /aries/trunk/blueprint: blueprint-bundle/ blueprint-itests/ blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/ blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/ blueprint-testbundlea/s
Date Fri, 25 Nov 2011 12:08:48 GMT
On 22 November 2011 21:10, Daniel Kulp <> wrote:

> On Tuesday, November 22, 2011 6:32:57 PM Jeremy Hughes wrote:
> > Hi Dan, I'm just catching up with what you're doing here. Back in
> > March we spent some time figuring out how to implement the OSGi
> > Semantic Versioning policy in our Maven build and release process. Zoe
> > documented it here:
> >
> >
> >
> > based discussions on the list, with the last one being here:
> >
> >
> > .27234.33.camel%40meschbix%3E
> >
> > There are some disparities with what you've change w.r.t what was
> > decided back then. I've made a comment in-line to this commit.
> ...........snip ..............
> > > -            <version>0.3</version>
> > > +            <version>0.3.2-SNAPSHOT</version>
> >
> > This should stay at 0.3 as there is no difference between trunk and
> > 0.3. blueprint 0.3.1 was released before we moved to the 'release by
> > bundle' process so it ended up releasing blueprint-api 0.3.1 even
> > there were no changes in it over 0.3. Can you describe how you have
> > decided what versions to use here and below? They really should be
> > depending on the released artifact. Thanks.
> Well, I would consider that a responsibility of the release manager (or on
> release branches) now to figure that  out.   On trunk, things really need
> to
> be geared toward the day to day work of the developers doing the work and
> making changes and fixing bugs.  For that, they need to be pointing at the
> snapshots for a variety of reasons:
> 1) Things like eclipse:eclipse will wire the projects together correctly so
> debugging and developing in the IDE works properly.
> 2) The tests (particularly the itests) actually test the code that is being
> developed on trunk.   If a developer makes a change in a SNAPSHOT and runs
> the
> tests, it should test the changes, not some release made 3 months ago.
> This
> is very important to me.   I want to be able to run "mvn test" before I
> commit
> and make sure everything works.
> 3) Related to (2), if a developer does make a change someplace, I really
> don't
> feel he should need to go off and find all the various places that need to
> be
> updated to make sure that change is fully tested.
> Remember, one of the goals of an Apache project is to expand the developer
> community.   That is best done by making sure the a new developer can jump
> in
> easily and start contributing without jumping through major learning curves
> and wacky and non-standard policies to get there.

This "wacky and non-standard" policy is there to ensure we can do the
"standard" OSGi practice of developing
independently releasable artefacts which are versioned using the standard
OSGi semantic versioning practice.
The goal here is different from yours. If we move everything up all the
time we may "know" that it works against
the latest, but it probably (in some cases certainly) no longer works
against the prior release of dependencies. So
we want to ensure we only up the dependency when we need a new capability
from it.

I guess the downside is testing against the latest, so we need a solution
to that, but it isn't to break our ability to work
with compatible prior releases of dependencies.

> Daniel Kulp
> -
> Talend Community Coder -

Alasdair Nottingham

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message