So you don't see any problem in not being *able to* delivery a bug fix bundle which will only fix a bug in two years ? Because it seems to me a direct consequence of a strict application of the semantic verisoning guidelines.
On Tue, Feb 8, 2011 at 11:52, Alasdair Nottingham <[email protected]> wrote: > The packages in util are all API, which is why they need to be > exported. Given that PropertyPlaceholder is exported so other people > can extend it I would argue that also makes it API, although I would > prefer to be able to hide the implementation details of blueprint. > > Alasdair > > On 7 February 2011 19:20, Guillaume Nodet <[email protected]> wrote: >> In blueprint-cm, we have >> org.apache.aries.blueprint.compendium.cm.CmPropertyPlaceholder >> inheriting org.apache.aries.blueprint.ext.PropertyPlaceholder. That's >> the first reason i've seen, there may be others. Aries-utils is also >> full of packages with code (well, it's purpose is to share code, so >> that's kinda expected). >> >> On Mon, Feb 7, 2011 at 20:12, Alasdair Nottingham <[email protected]> wrote: >>> 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] >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > > > > -- > Alasdair Nottingham > [email protected] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
