Return-Path: Delivered-To: apmail-aries-dev-archive@www.apache.org Received: (qmail 97887 invoked from network); 8 Feb 2011 10:52:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 8 Feb 2011 10:52:30 -0000 Received: (qmail 93835 invoked by uid 500); 8 Feb 2011 10:52:30 -0000 Delivered-To: apmail-aries-dev-archive@aries.apache.org Received: (qmail 93700 invoked by uid 500); 8 Feb 2011 10:52:28 -0000 Mailing-List: contact dev-help@aries.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@aries.apache.org Delivered-To: mailing list dev@aries.apache.org Received: (qmail 93692 invoked by uid 99); 8 Feb 2011 10:52:27 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Feb 2011 10:52:27 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of alasdair.nottingham@gmail.com designates 209.85.216.171 as permitted sender) Received: from [209.85.216.171] (HELO mail-qy0-f171.google.com) (209.85.216.171) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Feb 2011 10:52:22 +0000 Received: by qyk32 with SMTP id 32so249564qyk.2 for ; Tue, 08 Feb 2011 02:52:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=uy3ElM3X3nn8qcd+O9VETyfa+a0l8Szc6TRgrUVBg0Q=; b=Gb5yzi61L/JRrCwBTW9ftQd/RgDrlK7/hsw1yppV4o4dI6CurLrOu+hEuTsOeeQtNw Xbx541o6ozngg/ipPic8lVnL7cd+imC+83WaWtvKX7m2uHgt6PLJF0ZVt7imN8gjPenM a54AH6yV7x3OoaCaovwlb2BLBXSMhKuZ3Oft8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=AMzGheWLmWeXotdGrUkcaUSG7DwPkvdexMoihD6eFJ9Wy92/opQZMqmKX5luWkx4Nj IkR2COkMkrxkJjA8tyZO0IObpozzaBCiLQYZTxLvQS+wBYfYpZSal+XC0hPP43AMwHg2 jv/Ly59h56tu3aHoSAqDalsOXbAP1t3aQYOdE= MIME-Version: 1.0 Received: by 10.229.88.67 with SMTP id z3mr1923049qcl.138.1297162321601; Tue, 08 Feb 2011 02:52:01 -0800 (PST) Sender: alasdair.nottingham@gmail.com Received: by 10.229.121.5 with HTTP; Tue, 8 Feb 2011 02:52:01 -0800 (PST) In-Reply-To: References: <4D5007C3.7050707@gmail.com> Date: Tue, 8 Feb 2011 10:52:01 +0000 X-Google-Sender-Auth: r_tiM5qx5UkGeOACG_Lqp31zesI Message-ID: Subject: Re: Release / verisoning requirements (was Re: svn commit: r1066827 - /aries/branches/experimental-release-by-module/) From: Alasdair Nottingham To: dev@aries.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 wrote: > In blueprint-cm, we have > org.apache.aries.blueprint.compendium.cm.CmPropertyPlaceholder > inheriting org.apache.aries.blueprint.ext.PropertyPlaceholder. =A0That's > the first reason i've seen, there may be others. =A0Aries-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 wrote: >> If they aren't API then why are we exporting them? >> >> On 7 February 2011 16:53, Guillaume Nodet wrote: >>> On Mon, Feb 7, 2011 at 17:26, Timothy Ward wr= ote: >>>> >>>> >>>> >>>>> >>>> Before we go in any particular direction we must agree, that's t= rue. Is >>>>> >>>> it >>>>> >>>> possible to agree with these goals now: >>>>> >>>> >>>>> >>>> 1) As an OSGi project we must demonstrate best practice in our u= se 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 >>>>> >>>> =A0 =A0(a) A release of everything in one go with associated sam= ples which >>>>> >>>> are >>>>> >>>> therefore guaranteed to work together >>>>> >>>> =A0 =A0(b) Release by module - with the correctly versioned bund= les of >>>>> >>>> sub-modules >>>>> >>>> =A0 =A0(c) To avoid having to do release by sub-module (eg not h= aving to do >>>>> >>>> 17 >>>>> >>>> separate release steps for blueprint) >>>>> >>> >>>>> >>> Well, those are side issues imho and I think they conflict with t= he >>>>> >>> requirements I propose below. >>>>> >>> >>>>> >>> I'd rather have the following requirements: >>>>> >>> =A01. correct osgi semantic versioning >>>>> >>> =A02. 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) >>>>> >>> =A03. a release should have some release notes listing the change= s in >>>>> >>> that release >>>>> >>> =A04. a release must be publicly announced >>>>> >>> =A05. users should have an easy way to download the bundles neede= d for >>>>> >>> a given component (blueprint, etc...) >>>>> >>> =A06. easy tagging / branching mechanism >>>>> >>> >>>>> >> I'd also like to add those requirements: >>>>> >> =A0 =A07. a way to provide bug fix releases >>>>> >> =A0 =A08. a way to ensure that a given component does not have con= flicting >>>>> >> dependencies >>>>> >> >>>>> >> #7 is really important in my opinion, even more than #5 and #6. = =A0I >>>>> >> 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 hav= e >>>>> >> the ability to deploy a component which does not require two >>>>> >> dependencies with an incompatible version (i.e. for aries blueprin= t >>>>> >> x.y =A0we don't end up with requiring both aries-utils 1.x and >>>>> >> aries-utils 2.x). =A0This requirement is definitely not a must-hav= e, 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 wha= t we >>>>> >> want is a better idea than investigating a technical solution now.= =A0At >>>>> >> 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 m= y >>>>> > original suggestions? In any case I'm quite happy to abandon my sug= gestions >>>>> > in favour of yours. >>>>> > (b) I'm still trying to understand how we satisfy requirement "1. C= orrect >>>>> > osgi semantic versioning" >>>>> > >>>>> > Requirement 2, 3, 4 are relatively easy to satisfy. >>>>> > Requirements 5, 6, 7 are tied up in the semantic versioning discuss= ion and I >>>>> > believe that if we choose to implement semantic versioning there ar= e 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 disag= reement, >>>>> > although perhaps other people would like chip in with their views. >>>>> > As I said, the reason for experimenting is about how to satisfy req= uirement >>>>> > 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 in= compatible 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 unl= ikely 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. =A0We have several bundles that export packages that are >>> not real API and which contain code. =A0We're not talking about an idea= l >>> 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 >> not@apache.org >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > --=20 Alasdair Nottingham not@apache.org