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