If they aren't API then why are we exporting them? On 7 February 2011 16:53, Guillaume Nodet <[email protected]> wrote: > On Mon, Feb 7, 2011 at 17:26, Timothy Ward <[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. >> >> #1 and #7 are compatible as long as you don't change your API in an >> incompatible way (for anyone). This should be a requirement of an "in >> service" fix anyway so it isn't restrictive. Subsequent releases can export >> at the same version (assuming it contains the fix) or increment the micro >> version again if needs be. If you've written your bundles well the fix is >> very unlikely to affect a package version anyway, requiring only a micro >> increment to the bundle version. This doesn't seem incompatible with #7 at >> all. > > That's would only work if we have package versions on pure API > packages only. We have several bundles that export packages that are > not real API and which contain code. We're not talking about an ideal > world here, but about real code. > >> >> Tim >> >>> >>> > Zoe >>> >> >>> >> >>> >> >>> > >>> > >>> >>> >>> >>> -- >>> 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 >
-- Alasdair Nottingham [email protected]
