Am Dienstag, den 08.02.2011, 13:06 +0000 schrieb Alasdair Nottingham: > 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.
+1 Regards Felix > > 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 > > > > >
