We'd have to add a use clause to make sure the plugin is wired to two compatible packages. Apart from that, I think it should work, but i'm still not convinced about that. It add more maintenance on both sides without much added value.
On Wed, Jun 16, 2010 at 09:33, Felix Meschberger <fmesc...@gmail.com> wrote: > Hi, > > On 15.06.2010 23:22, Justin Edelson wrote: >> On Tue, Jun 15, 2010 at 4:59 PM, Guillaume Nodet <gno...@gmail.com> wrote: >> >>> On Tue, Jun 15, 2010 at 15:05, Felix Meschberger <fmesc...@gmail.com> >>> wrote: >>>> Hi, >>>> >>>> On 15.06.2010 14:49, Guillaume Nodet wrote: >>>>> What if you change the semantic of a function call without changing the >>>>> signature ? >>>>> I guess that's an incompatible change in theory, though still binary >>>>> compatible. So we can't limit to binary compatibility for versioning >>> imho, >>>>> which mean there is some semantic involved. >>>> >>>> Yes, agreed, this is in fact an API change - and therefore requires an >>>> update in the exported package version. >>>> >>>> Nevertheless: I would say, that changing the semantics of a method is >>>> dangerous, just because it involves no change on the invocation level. >>>> So I would think, that changing the semantics of a method is even more >>>> dangerous than an incompatible API change. >>>> >>>>> >>>>> If you expect the user to take an action when upgrading, it means there >>> is a >>>>> (somewhat) incompatible change imho. >>>> >>>> Really depends on the kind of upgrade. >>>> >>>> Consider for example the Web Console upgrading to the next JQuery >>>> release. This would require a new Web Console release with an increased >>>> bundle version number. >>>> >>>> But since nothing in the API changes as a consequence of this JQuery >>>> upgrade, we must not increase the exported package version number ! >>>> >>>> BTW: [1] is highly recommended reading ! >>> >>> The document actually clearly talks about semantic compatibility. >>> >>> The question then comes down to: is the environment provided by the >>> webconsole to the plugin part of the semantic of the package exported. >>> I would think so. >> >> Why? The Java package org.apache.felix.webconsole should be able to be >> versioned independently of any front-end code. Just because there isn't a >> great way to expose/consume the version of the JavaScript libraries doesn't >> mean you should overload the meaning of the package version. >> >> >>> Which leads me to have to bump the major version >>> of the package if the html output of the plugin won't work anymore. >>> >> >> >> One thing that might work is to define a synthetic package representing the >> front-end environment. But this would be versioned independently from the >> Java package(s) the bundle exports. I'm just not sure how BND behaves when >> you tell it to include an Export-Package header for a package which doesn't >> exist. > > Interesting approach. I quickly tested exporting the res.lib package, > which is the res/lib folder containing the JQuery libraries. This works > perfectly. > > So, we could move the JQuery libraries to a new package, say > org.apache.felix.webconsole.js, and export this package. Whenever we > upgrade one of the libraries, we could increase the export version there. > > Consuming bundles could import that package and be sure to correctly > wire; if they wished. > > WDYT ? > > Regards > Felix > >> >> Justin >> >> >>> >>> Note the title of this document is really "semantic versioning", not >>> "binary compatibility". Though binary compatibility is usually a >>> great deal, it is clearly not sufficient to capture the whole semantic >>> versioning of a given package ... >>> >>>> >>>> Regards >>>> Felix >>>> >>>> [1] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf >>>> >>>>> >>>>> On Tue, Jun 15, 2010 at 14:36, Alasdair Nottingham <n...@apache.org> >>> wrote: >>>>> >>>>>> +1 a package version change reflects a change to the package, not a >>>>>> change to the implementation. >>>>>> >>>>>> On 15 June 2010 13:27, Felix Meschberger <fmesc...@gmail.com> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 15.06.2010 14:20, Guillaume Nodet wrote: >>>>>>>> On Tue, Jun 15, 2010 at 14:15, Felix Meschberger <fmesc...@gmail.com >>>> >>>>>> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 15.06.2010 13:38, Guillaume Nodet wrote: >>>>>>>>>> Usually, users would use a range, so it should not matter that much >>> I >>>>>>>>> think. >>>>>>>>> >>>>>>>>> Yes and no. >>>>>>>>> >>>>>>>>> The problem is, that the bundle version may evolve independently of >>> the >>>>>>>>> API export version. >>>>>>>>> >>>>>>>>> Consider for example that we decide to release a 4.0 version of the >>> Web >>>>>>>>> Console in the future whereas the API did not change at all. In this >>>>>>>>> case, we should still export the API as 3.1 to not break existing >>>>>>>>> plugins which import the API as [3.1,3.2). >>>>>>>>> >>>>>>>> >>>>>>>> And why would be bump the version if there's no change ? >>>>>>> >>>>>>> Where's the change ? The Web Console bundle exports API and contains >>>>>>> implementation. As such the Web Console bundle attaches a version to >>> the >>>>>>> exported package and to the bundle itself. >>>>>>> >>>>>>> But: We must not mix the semantic of the version of the API export >>> with >>>>>>> the semantic of the bundle version, which also includes implementation >>>>>> code. >>>>>>> >>>>>>>> Even if the >>>>>>>> package did not actually change, if there was a need for the major >>>>>> version >>>>>>>> to be bumped, i'd rather reflect that on the package version as well, >>> to >>>>>>>> make sure people are aware of those major changes (and change their >>>>>> version >>>>>>>> range if needed). >>>>>>> >>>>>>> No, please not. >>>>>>> >>>>>>> The export package version has semantic meaning to the importers >>> (users, >>>>>>> implementors) of the exported package. >>>>>>> >>>>>>> The bundle version on the other hand has semantic meaning to the >>> (human) >>>>>>> users of the web console at large. >>>>>>> >>>>>>> If we upgrade the export version of the package, just because we >>>>>>> modified some internal implementation, this will break plugins for >>>>>>> nothing worth -- except making (human) users and administrators >>> unhappy >>>>>>> because we require them to upgrade plugins ... >>>>>>> >>>>>>> Granted, if the internal implementation causes the API to change we >>> must >>>>>>> increment the version of the exported package. >>>>>>> >>>>>>> But in no case should the version of an exported package be >>> incremented >>>>>>> just because the internal implementation changed without influence on >>>>>>> the exported package contents.... >>>>>>> >>>>>>> Regards >>>>>>> Felix >>>>>>> >>>>>>> >>>>>>>> For example, from 2.x to 3.x, the UI has been redesigned, but the >>>>>> package >>>>>>>> could have been backward compatible (is it ?). But even if it is >>>>>>>> compatible, i'd rather upgrade it to 3.x, because i'd rather have >>> users >>>>>> be >>>>>>>> aware that they need to rewrite the plugins to adapt to the new ui >>> ... >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> I've used the pom.version for 3.1.0, which an be change afterward >>> if >>>>>> we >>>>>>>>> want >>>>>>>>>> to keep at 3.1.0 for the package version for future releases. >>>>>>>>> >>>>>>>>> Ok. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Felix >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Jun 15, 2010 at 13:15, Felix Meschberger < >>> fmesc...@gmail.com> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 15.06.2010 12:58, Guillaume Nodet wrote: >>>>>>>>>>>> Wow, I was expecting the package to be derived from the project >>>>>>>>> version. >>>>>>>>>>> >>>>>>>>>>> No, because I don't want to increase the export version on each >>>>>> bundle >>>>>>>>>>> release. The downside is, that it must not be forgotten to be >>>>>> increased >>>>>>>>>>> when there is some change in the API. >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Felix >>>>>>>>>>> >>>>>>>>>>>> I'll fix that now. >>>>>>>>>>>> >>>>>>>>>>>> Cancelling this release again. ... >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jun 15, 2010 at 12:46, Felix Meschberger < >>>>>> fmesc...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> On 15.06.2010 11:47, Guillaume Nodet wrote: >>>>>>>>>>>>>> I would like to call a new vote on the following subproject >>>>>> releases: >>>>>>>>>>>>>> >>>>>>>>>>>>>> webconsole 3.1.0 >>>>>>>>>>>>> >>>>>>>>>>>>> Still exports web console API 3.0 ... >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Felix >>>>>>>>>>>>> >>>>>>>>>>>>>> bundlerepository 1.6.4 >>>>>>>>>>>>>> karaf 1.6.2 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Staging repository: >>>>>>>>>>>>>> >>>>>>>>> >>> https://repository.apache.org/content/repositories/orgapachefelix-053/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> You can use this UNIX script to download the release and verify >>>>>> the >>>>>>>>>>>>>> signatures: >>>>>>>>>>>>>> >>>>>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh >>>>>>>>>>>>>> >>>>>>>>>>>>>> Usage: >>>>>>>>>>>>>> sh check_staged_release.sh 053 /tmp/felix-staging >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please vote to approve this release: >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ ] +1 Approve the release >>>>>>>>>>>>>> [ ] -1 There's a problem (please provide specific comments) >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Alasdair Nottingham >>>>>> n...@apache.org >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> 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
