Hi, I think it was Tim who made an important statement: Given Aries would go for semantic versioning and you go losening it allowing for intermediate version updates to give way for potential future updates you would alienate clients holding on to semantic versioning.
Consider: Aries provides blurb, v 1.0 Client uses blurb, v [1.0,1.1) Aries releases blurb v 1.1 without changes Client fails ... Regards Felix Am Dienstag, den 08.02.2011, 13:46 +0100 schrieb Guillaume Nodet: > 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] > > > > >
