You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2010/06/15 14:49:25 UTC

Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2 (2nd try))

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.

If you expect the user to take an action when upgrading, it means there is a
(somewhat) incompatible change imho.

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
>



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

Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2 (2nd try))

Posted by Alasdair Nottingham <no...@apache.org>.
I agree.

On 15 June 2010 14: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 !
>
> 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
>>>
>>
>>
>>
>



-- 
Alasdair Nottingham
not@apache.org

Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2 (2nd try))

Posted by Guillaume Nodet <gn...@gmail.com>.
On Wed, Jun 16, 2010 at 23:47, Justin Edelson <ju...@gmail.com> wrote:
> On 6/16/10 5:36 PM, Guillaume Nodet wrote:
>> On Wed, Jun 16, 2010 at 23:30, Justin Edelson <ju...@gmail.com> wrote:
>>> How could the use clause be used for JavaScript code? It is only
>>> relevant when there is more than one exporter of a package.
>>
>> A use clause from the javascript package on to the main webconsole
>> package would ensure that importer of the javascript package can't be
>> wired on to an imcompatible webconsole package.   If you don't add
>> this clause and have a webconsole 3.x and 3.y, you might end up being
>> wired on to both versions.
> Except that the "wiring" between the JavaScript bundles actually happens
> at the client-side. If you had webconsole 3.x and 3.y bundles installed,
> which version would be served is determined by which bundle's activator
> got to HttpService first.
>

If each HttpService exports its own javax.servlet package and check
for compatibility, each servlet can only be wired to a single
HttpService instance.

There's work going on about extenders in the OSGi Alliance, hopefully
we'll have a nice way to handle those problems.

>>
>>> This looks like the type of semantic confusion which arises from
>>> repurposing manifest headers to represent something they were not meant
>>> to represent.
>>
>> Exporting a package with nothing, for the purpose of specifiying a
>> provided environment (in this case javascript) sounds like a repurpose
>> to me...
> It is a repurpose. But didn't this start with you wanting to repurpose
> the version of the Java package to specify the version of the front-end
> environment?

In this case, the plugin  is asked by the webconsole to compute something that
the webconsole will use.  If the way the computation needs to be done needs to
change because the webconsole handle the result in a different way, then surely
there is an incompatible change.

As I said, I consider that this is part of the semantic implied when
writing a plugin,
so I still think it should be associated to the main package.

So it's not about trying to version JQuery per se, it's about the
semantics of the
renderContent() method, nothing more than that.

> To be clear, my desire would be to have the OSGi Alliance define the
> right headers and have HttpService enhanced to take advantage of them.
> Barring that, an empty marker package is just the least worst choice IMHO.
>
> Justin
>
>>
>>>
>>> Justin
>>>
>>> On 6/16/10 3:57 AM, Guillaume Nodet wrote:
>>>> 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 <fm...@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 15.06.2010 23:22, Justin Edelson wrote:
>>>>>> On Tue, Jun 15, 2010 at 4:59 PM, Guillaume Nodet <gn...@gmail.com> 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 !
>>>>>>>>
>>>>>>>> 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 <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 <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

Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2 (2nd try))

Posted by Justin Edelson <ju...@gmail.com>.
On 6/16/10 5:36 PM, Guillaume Nodet wrote:
> On Wed, Jun 16, 2010 at 23:30, Justin Edelson <ju...@gmail.com> wrote:
>> How could the use clause be used for JavaScript code? It is only
>> relevant when there is more than one exporter of a package.
> 
> A use clause from the javascript package on to the main webconsole
> package would ensure that importer of the javascript package can't be
> wired on to an imcompatible webconsole package.   If you don't add
> this clause and have a webconsole 3.x and 3.y, you might end up being
> wired on to both versions.
Except that the "wiring" between the JavaScript bundles actually happens
at the client-side. If you had webconsole 3.x and 3.y bundles installed,
which version would be served is determined by which bundle's activator
got to HttpService first.

> 
>> This looks like the type of semantic confusion which arises from
>> repurposing manifest headers to represent something they were not meant
>> to represent.
> 
> Exporting a package with nothing, for the purpose of specifiying a
> provided environment (in this case javascript) sounds like a repurpose
> to me...
It is a repurpose. But didn't this start with you wanting to repurpose
the version of the Java package to specify the version of the front-end
environment?

To be clear, my desire would be to have the OSGi Alliance define the
right headers and have HttpService enhanced to take advantage of them.
Barring that, an empty marker package is just the least worst choice IMHO.

Justin

> 
>>
>> Justin
>>
>> On 6/16/10 3:57 AM, Guillaume Nodet wrote:
>>> 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 <fm...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> On 15.06.2010 23:22, Justin Edelson wrote:
>>>>> On Tue, Jun 15, 2010 at 4:59 PM, Guillaume Nodet <gn...@gmail.com> 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 !
>>>>>>>
>>>>>>> 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 <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 <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
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
> 
> 
>

Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2 (2nd try))

Posted by Guillaume Nodet <gn...@gmail.com>.
On Wed, Jun 16, 2010 at 23:30, Justin Edelson <ju...@gmail.com> wrote:
> How could the use clause be used for JavaScript code? It is only
> relevant when there is more than one exporter of a package.

A use clause from the javascript package on to the main webconsole
package would ensure that importer of the javascript package can't be
wired on to an imcompatible webconsole package.   If you don't add
this clause and have a webconsole 3.x and 3.y, you might end up being
wired on to both versions.

> This looks like the type of semantic confusion which arises from
> repurposing manifest headers to represent something they were not meant
> to represent.

Exporting a package with nothing, for the purpose of specifiying a
provided environment (in this case javascript) sounds like a repurpose
to me...

>
> Justin
>
> On 6/16/10 3:57 AM, Guillaume Nodet wrote:
>> 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 <fm...@gmail.com> wrote:
>>> Hi,
>>>
>>> On 15.06.2010 23:22, Justin Edelson wrote:
>>>> On Tue, Jun 15, 2010 at 4:59 PM, Guillaume Nodet <gn...@gmail.com> 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 !
>>>>>>
>>>>>> 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 <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 <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

Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2 (2nd try))

Posted by Justin Edelson <ju...@gmail.com>.
How could the use clause be used for JavaScript code? It is only
relevant when there is more than one exporter of a package.

This looks like the type of semantic confusion which arises from
repurposing manifest headers to represent something they were not meant
to represent.

Justin

On 6/16/10 3:57 AM, Guillaume Nodet wrote:
> 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 <fm...@gmail.com> wrote:
>> Hi,
>>
>> On 15.06.2010 23:22, Justin Edelson wrote:
>>> On Tue, Jun 15, 2010 at 4:59 PM, Guillaume Nodet <gn...@gmail.com> 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 !
>>>>>
>>>>> 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 <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 <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
>>>>
>>>
>>
> 
> 
>

Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2 (2nd try))

Posted by Guillaume Nodet <gn...@gmail.com>.
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 <fm...@gmail.com> wrote:
> Hi,
>
> On 15.06.2010 23:22, Justin Edelson wrote:
>> On Tue, Jun 15, 2010 at 4:59 PM, Guillaume Nodet <gn...@gmail.com> 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 !
>>>>
>>>> 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 <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 <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

Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2 (2nd try))

Posted by Karl Pauls <ka...@gmail.com>.
Not sure I understand the issue completely but it sounds like you have
a hidden dependency on something. The way I typically try to handle
this is to add a mandatory attribute for the hidden dependency version
to the package so that importers must specify the correct value there.
Again, this may or may not make sense in your case.

regards,

Karl

On Wed, Jun 16, 2010 at 4:04 PM, Justin Edelson <ju...@gmail.com> wrote:
> On 6/16/10 3:33 AM, Felix Meschberger wrote:
>> Hi,
>>
>> On 15.06.2010 23:22, Justin Edelson wrote:
>>>
>>> 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 ?
> The problem with this approach is that you're exporting these resources
> via the OSGi framework unnecessarily. Other bundles don't actually need
> to do
> ClassLoader.getResource("/org/apache/felix/webconsole/js/jquery.js").
> This isn't THAT big of a deal, but it is a leak.
>
> Nonetheless, I think this is the best you can do with the tools we have.
>
> Perhaps we should move this discussion to osgi-dev?
>
> Justin
>
>>
>> Regards
>> Felix
>>
>



-- 
Karl Pauls
karlpauls@gmail.com

Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2 (2nd try))

Posted by Justin Edelson <ju...@gmail.com>.
On 6/16/10 3:33 AM, Felix Meschberger wrote:
> Hi,
> 
> On 15.06.2010 23:22, Justin Edelson wrote:
>>
>> 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 ?
The problem with this approach is that you're exporting these resources
via the OSGi framework unnecessarily. Other bundles don't actually need
to do
ClassLoader.getResource("/org/apache/felix/webconsole/js/jquery.js").
This isn't THAT big of a deal, but it is a leak.

Nonetheless, I think this is the best you can do with the tools we have.

Perhaps we should move this discussion to osgi-dev?

Justin

> 
> Regards
> Felix
>

Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2 (2nd try))

Posted by Felix Meschberger <fm...@gmail.com>.
Hi,

On 15.06.2010 23:22, Justin Edelson wrote:
> On Tue, Jun 15, 2010 at 4:59 PM, Guillaume Nodet <gn...@gmail.com> 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 !
>>>
>>> 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 <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 <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
>>
>

Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2 (2nd try))

Posted by Justin Edelson <ju...@justinedelson.com>.
On Tue, Jun 15, 2010 at 4:59 PM, Guillaume Nodet <gn...@gmail.com> 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 !
> >
> > 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.

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

Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2 (2nd try))

Posted by Guillaume Nodet <gn...@gmail.com>.
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 !
>
> 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.  Which leads me to have to bump the major version
of the package if the html output of the plugin won't work anymore.

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



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

Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2 (2nd try))

Posted by Justin Edelson <ju...@gmail.com>.
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
>>>>
>>>>         
>>>
>>>       
>
>
>
>

Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2 (2nd try))

Posted by Guillaume Nodet <gn...@gmail.com>.
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.

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



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

Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2 (2nd try))

Posted by Felix Meschberger <fm...@gmail.com>.
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 <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
>>
> 
> 
>