Fair enough, so *any* change is not a bug fix, even fully compatible, require a bump in the minor version. That would be ok with me, but that's not what I had understood.
On Tue, Feb 8, 2011 at 14:06, Alasdair Nottingham <[email protected]> wrote: > 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] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
