I don't understand what "problem" you have raised. I do not understand why you think that semantic versioning is not compatible with bug fixing.
I know there are problems with a tree of releases, but the problems don't relate to bug fixes, but trying to do functional enhancements in a 0.2 stream while 0.3 exists. This is not a "bug fix" problem, but a development problem and in my view we should not be putting functional enhancements and API changes into back level versions of our codebase. By being careful what we consider a "bug" fix we don't have this problem. Alasdair On 8 February 2011 12:46, Guillaume Nodet <[email protected]> wrote: > 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 > -- Alasdair Nottingham [email protected]
