You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Justin Edelson <ju...@gmail.com> on 2010/06/15 21:49:11 UTC
Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository
1.6.4, karaf 1.6.2 (2nd try))
Guillaume Nodet wrote:
> On Tue, Jun 15, 2010 at 15:05, Felix Meschberger <fm...@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 !
>>
>>
>
> Unless the existing plugins can't be made to work with the new JQuery ...
> In that case, a version bump would be required.
>
JQuery is not part of the exported Java package org.apache.felix.webconsole.
How to apply OSGi concepts in general for JavaScript is a very
interesting subject. Until there's an established standard, I suspect
the only thing which can be done is to use the bundle version.
Justin
>
>> 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 <no...@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 <fm...@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On 15.06.2010 14:20, Guillaume Nodet wrote:
>>>>>
>>>>>> On Tue, Jun 15, 2010 at 14:15, Felix Meschberger <fm...@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 <fm...@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 <
>>>>>>>>>>
>>>> fmeschbe@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
>>>> not@apache.org
>>>>
>>>>
>>>
>>>
>
>
>
>