On Mon, Feb 7, 2011 at 15:54, zoe slattery <[email protected]> wrote: > >>>> 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 didn't reply earlier because: > > (a) I'm not sure what in your requirements conflicts exactly with my > original suggestions? In any case I'm quite happy to abandon my suggestions > in favour of yours. > (b) I'm still trying to understand how we satisfy requirement "1. Correct > osgi semantic versioning" > > Requirement 2, 3, 4 are relatively easy to satisfy. > Requirements 5, 6, 7 are tied up in the semantic versioning discussion and I > believe that if we choose to implement semantic versioning there are at > least some implications for the way in which we meet requirements 5, 6, and > 7. Not sure about 8. > > So, as a list of requirements I don't think there is too much disagreement, > although perhaps other people would like chip in with their views. > As I said, the reason for experimenting is about how to satisfy requirement > 1 with the others. I feel that it's rather poor form that we (as an OSGi > project) don't meet requirement 1 at the moment :-) >
Well, given I still haven't understood how we're going to release things (per bundle or per component, as it seems a single whole release hasn't really received much support), I think our current layout conflict with #6 and we still haven't found a clear way to align #1 with #7 afaik. > Zoe >> >> >> > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
