I agree. On 15 June 2010 14: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 ! > > 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 >>> >> >> >> >
-- Alasdair Nottingham n...@apache.org
