On 2 December 2011 03:49, David Jencks <[email protected]> wrote: > 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.
+1 I agree. This has been percolating through the back of my mind the last few days too. > > 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 would we have to do this using a set of maintained properties files? Where would this go - in the parent pom, the top level module pom or the bundle pom. There's a file her http://svn.apache.org/repos/asf/aries/trunk/aries_release_versions.txt which is supposed to reflect the latest versions - although I think a maven plugin could be written and teased into figuring out the latest. > > 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] >
