On Fri, Feb 4, 2011 at 14:44, Guillaume Nodet <[email protected]> wrote: > 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'd also like to add those requirements: 7. a way to provide bug fix releases 8. a way to ensure that a given component does not have conflicting dependencies #7 is really important in my opinion, even more than #5 and #6. I can't even imagine how I would tell my customers I can't even do a bug fix release. #8 is about mitigating the dependency hell so that we actaully have the ability to deploy a component which does not require two dependencies with an incompatible version (i.e. for aries blueprint x.y we don't end up with requiring both aries-utils 1.x and aries-utils 2.x). This requirement is definitely not a must-have, but a nice to have, as it's really for ease of use and consumption of our components. I haven't heard any feedback so far, but I think starting from what we want is a better idea than investigating a technical solution now. At least discussing those requirements may end up to doing some compromise over others if they are somewhat incompatible (i..e we don't find a technical solution to solve all those requirements). > > 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 > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
