So do you think we should weaken the semantic versioning guidelines in order to accomodate being able to do bug fix releases ? Or is there a better alternative ?
I know you haven't implied anything, but if nobody imply nor say anything, it doesn't really help solving the problems i've raised. On Tue, Feb 8, 2011 at 13:41, Alasdair Nottingham <[email protected]> wrote: > 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] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
