On 4 February 2011 13:11, zoe slattery <[email protected]> wrote: > On 04/02/2011 12:33, Guillaume Nodet wrote: >> >> Afaik, the maven release plugin can actually release several maven >> projects at the same time each one having its own release number. >> Meaning when you release a project consisting of several maven >> subprojects, each one can have its own release version (whether or not >> that's desirable is a completely different problem). > > Yes, I think it can. >> >> On the osgi versioning problem, I'm not sure we have to assume that >> the version number of the package is the same as the one for the >> bundle, so the fact you need to specify a range isn't related to the >> release process. > > No - it's part of the development process. I think it _is_ assumed by what > is in our default parent pom at the moment. >> >> The maven bundle plugin can automatically generate a >> range based on the information it finds, so here again, it's related >> to the package versioning, not the bundle versioning. Please remember >> that the semantic associated to the version in OSGi is at the package >> level, not the bundle level. > > Understood. >> >> Last, I'm not sure we're going into the right direction. I think >> those decisions should not be bound to technical considerations so >> early in the process. > > I don't think we are going in any particular direction at the moment - or at > least I'm not. The reason for the experimental branch was to > try and understand more about what we would have to do to get semantic > versioning correct for both bundles and packages. >> >> I'm quite sure we have a lot of freedom in choosing how we want to >> version things and release them. >> >> Maybe we should start by stating by agreeing on what we'd like first. > > Before we go in any particular direction we must agree, that's true. Is it > possible to agree with these goals now: > > 1) As an OSGi project we must demonstrate best practice in our use of > semantic versioning at bundle and package level
I think it's more than this - Aries isn't just an OSGi project, it's infrastructure to enable OSGi based applications. We need to demonstrate how semantic versioning can be be achieved throughout the lifecycle of a multi-bundle project, so that others can learn and follow that. > 2) A build and release process which allows us to do > (a) A release of everything in one go with associated samples which are > therefore guaranteed to work together By this I take it you mean a release of all the releasable code we have in one go. I'd like to point out that we don't really have this today - we just happen to do a release for each of the top level modules and vote for them at the same time. I think this is: release all the artifacts that have changes and hence need a release and at the same time release a roll-up of all those new artifacts and all the others that didn't need a release. By doing this roll-up release we'd be making a statement about the level of testing that had been done with that combination of released child artifacts. > (b) Release by module - with the correctly versioned bundles of > sub-modules A bit like (a) but for a single module (that potentially contains child modules / bundles itself) > (c) To avoid having to do release by sub-module (eg not having to do 17 > separate release steps for blueprint) Agreed. > > Z >> >> On Fri, Feb 4, 2011 at 13:18, zoe slattery<[email protected]> wrote: >>> >>> On 03/02/2011 22:28, Guillaume Nodet wrote: >>>> >>>> What kind of experiments do you have in mind ? >>> >>> Probably this is more to do with my understanding (or lack of) of the way >>> in >>> which the current maven >>> build specifies versions and how the release process deals with them. >>>> >>>> I'm not sure to actually understand how the release process will be >>>> different if we release everyting in one go, component by component, >>>> or bundle by bundle. At the end, it always comes down to the same >>>> steps: updating pom dependencies, mvn release:prepare release:perform, >>>> updating jira, vote, updating the web site, annoucement. >>>> The obvious different will be at which level you run the command from, >>>> but apart from that, I kinda fail to see what kind of impact it would >>>> have. >>> >>> The aim is to keep the release process the same, as you say. To take a >>> specific example, I was looking at the quiesce module, the sort of thing >>> that the pom.xml would need to indicate is: >>> >>> 1) Quiesce module depends on released versions of parent, testsupport, >>> util >>> (this is easy) >>> 2) Quiesce module depends on a released version of the quiesce api (one >>> of >>> the agregator's sub-modules) but development versions of the >>> implementation >>> sub-modules. >>> >>> At the moment to make step 2 work it's necessary to override the default >>> package imports for, say, the quiesce manager implementation and comment >>> out quiesce-api in the modules section. After that I get something which >>> builds and runs - the quiesce manager implementation bundle has the >>> correct >>> package imports. I've checked in the quiesce pom (with debug in it). I'm >>> not >>> quite sure what the release process will do with this, so I need to >>> check. >>> >>> >>> Zoe >>> >>> >>>> On Thu, Feb 3, 2011 at 16:11,<[email protected]> wrote: >>>>> >>>>> Author: zoe >>>>> Date: Thu Feb 3 15:11:33 2011 >>>>> New Revision: 1066827 >>>>> >>>>> URL: http://svn.apache.org/viewvc?rev=1066827&view=rev >>>>> Log: >>>>> recreating with 0.4 from trunk >>>>> >>>>> Added: >>>>> aries/branches/experimental-release-by-module/ >>>>> - copied from r1066825, aries/trunk/ >>>>> >>>>> >>>> >>> >> >> > >
