On Dec 2, 2011, at 2:39 AM, Jeremy Hughes wrote: > 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.
I think the versions need to be maintained in each (leaf) pom for artifacts we release. Otherwise there's no good way to release single artifacts. There's the versions-maven-plugin http://mojo.codehaus.org/versions-maven-plugin/ that helps with updating versions but I don't know if it is smart enough to work with version properties in a profile. If the plugin doesn't work, if we use a consistent version naming scheme its easy enough to use an IDE's search-and-replace to update properties. thanks david jencks > >> >> 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] >>
