How could the use clause be used for JavaScript code? It is only relevant when there is more than one exporter of a package.
This looks like the type of semantic confusion which arises from repurposing manifest headers to represent something they were not meant to represent. Justin On 6/16/10 3:57 AM, Guillaume Nodet wrote: > 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 >>>> >>> >> > > >
