On Fri, Feb 4, 2011 at 14: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
Agreed, though I don't think there's much semantic implied at the bundle level. > 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 > (b) Release by module - with the correctly versioned bundles of > sub-modules > (c) To avoid having to do release by sub-module (eg not having to do 17 > separate release steps for blueprint) Well, those are side issues imho and I think they conflict with the requirements I propose below. I'd rather have the following requirements: 1. correct osgi semantic versioning 2. a release must have a buildable source distribution (that's really an asf requirement, as the source distribution *is* really the release from an asf pov) 3. a release should have some release notes listing the changes in that release 4. a release must be publicly announced 5. users should have an easy way to download the bundles needed for a given component (blueprint, etc...) 6. easy tagging / branching mechanism I think #1 implies that the package versioning should not be tied to the bundle version, as uber-bundles will definitely contain several different versions for their included packages (and that's already the case when we ship an osgi spec package for example. #2 is an ASF requirement afaik. Felix has a per-bundle release policy and each bundle comes with its own buildable distribution, see http://repo2.maven.org/maven2/org/apache/felix/org.apache.felix.fileinstall/3.1.6/org.apache.felix.fileinstall-3.1.6-project.tar.gz for example. I'm really convinced with a per-bundle release policy for Aries #3 is really important for our users and I think we need to leverage JIRA for that. Meaning for each *release* (being per-bundle, per-component, or per-aries), we need to have a changelog either in svn or on the website. And it need to be consistent, i.e. if we allow per-bundle releases, all release notes should be per-bundle, else there's no real way to find your way around. #4 is a brainer if we want to actually create a community for our users #5 is important for beginners and I'd also say that for downstream users, we want to have an easy way to know which bundles are supposed to work together (and tested). I don't necessarily imply we need a zip that the user can download, a web page stating all the (up-to-date) dependencies for a given component could be sufficient. #6 i think that can be argued, but for maintenance branches, tags and all, I think it's way easier if we have a trunk/tags/branch setup per release-cycle, else it becomes really difficult to follow. For the past releases, we had a per-component release cycle, but not a per-component trunk/tags/branch set up. I think that's not the best option. Such a set up would also allow us to create predicatable maintenance branches. For example, there's no easy way to find where the application-0.2.1 release which is under way come from (well, currently, given the very low number of releases, it's not very difficult, but if we version components independantly, how will you call the branch ?) Feedback welcome ! > 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/ >>>>> >>>>> >>>> >>> >> >> > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
