I think there are two valid goals here with conflicting requirements: - make sure that individual artifacts continue to work against at least one already-released version
- make sure that all the individual artifacts continue to work together as they are developed. I think these are both really worthwhile goals. I suggest we solve this conflict using profiles and have jenkins run two builds using the profiles. We can discuss whether one of the profiles should be default, I think the "released version" profile would be a better default but I don't think this is very important. Anyway each bundle project would have two profiles perhaps released - contains version properties for dependencies at the oldest released version we expect the project bundle to work against dev - contains version properties for dependencies at the current snapshot version thoughts? thanks david jencks On Nov 25, 2011, at 4:08 AM, Alasdair Nottingham wrote: > On 22 November 2011 21:10, Daniel Kulp <[email protected]> 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: >>> >>> 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. >> > > 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 >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> > > > > -- > Alasdair Nottingham > [email protected]
