I have made no such statement, nor have I implied any such thing. Alasdair
On 8 February 2011 12:18, Guillaume Nodet <[email protected]> wrote: > 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 > -- Alasdair Nottingham [email protected]
