felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2 (2nd try))
Date Wed, 16 Jun 2010 07:57:37 GMT
We'd have to add a use clause to make sure the plugin is wired to two
compatible packages.
Apart from that, I think it should work, but i'm still not convinced
about that.  It add more
maintenance on both sides without much added value.

On Wed, Jun 16, 2010 at 09:33, Felix Meschberger <fmeschbe@gmail.com> wrote:
> Hi,
>
> On 15.06.2010 23:22, Justin Edelson wrote:
>> On Tue, Jun 15, 2010 at 4:59 PM, Guillaume Nodet <gnodet@gmail.com> wrote:
>>
>>> On Tue, Jun 15, 2010 at 15:05, Felix Meschberger <fmeschbe@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.
>
> Interesting approach. I quickly tested exporting the res.lib package,
> which is the res/lib folder containing the JQuery libraries. This works
> perfectly.
>
> So, we could move the JQuery libraries to a new package, say
> org.apache.felix.webconsole.js, and export this package. Whenever we
> upgrade one of the libraries, we could increase the export version there.
>
> Consuming bundles could import that package and be sure to correctly
> wire; if they wished.
>
> WDYT ?
>
> Regards
> Felix
>
>>
>> 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 <not@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 <fmeschbe@gmail.com>
wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 15.06.2010 14:20, Guillaume Nodet wrote:
>>>>>>>> On Tue, Jun 15, 2010 at 14:15, Felix Meschberger <fmeschbe@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
<
>>> fmeschbe@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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
View raw message