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. 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 >
