aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
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 Tue, 22 Nov 2011 21:10:47 GMT
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.

Daniel Kulp -
Talend Community Coder -

View raw message