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: > > http://aries.apache.org/development/versionpolicy.html > > based discussions on the list, with the last one being here: > > http://mail-archives.apache.org/mod_mbox/aries-dev/201103.mbox/%3C1300364661 > .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 [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
