+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 <[email protected]> wrote: > Hi, > > On 15.06.2010 14:20, Guillaume Nodet wrote: >> On Tue, Jun 15, 2010 at 14:15, Felix Meschberger <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>>> 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 [email protected]
