Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of gnodet@gmail.com designates
 74.125.82.177 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=tqslgIgu47zry7mDYZzdjRz0U5Ihz7NYZqhqDmDqNugONZt7G2pd9XObHt+vDDahB2
         7tMM5R2rFecYCuX0aUvPRgE5DWtst/4eVjYmg349z+N2EYeX0b7CyLmK3+9tOAsCPWdc
         CgGWAOOhhTm4wRlORR1KsLkGpKsL97jBv/BLY=
MIME-Version: 1.0
In-Reply-To: <4C177A84.9090005@gmail.com>
References: <AANLkTinee7yDSG96JU53wn5hNbgxOtIZR1y0_TY7p823@mail.gmail.com>
	<4C177A84.9090005@gmail.com>
Date: Tue, 15 Jun 2010 22:59:10 +0200
Message-ID: <AANLkTimzL4VMztSuS-9oeqVyerQuFtE3c8kSSdMy0C0j@mail.gmail.com>
Subject: Re: Package versioning (was Re: [VOTE] Release webconsole 3.1.0
	bundlerepository 1.6.4, karaf 1.6.2 (2nd try))
From: Guillaume Nodet <gnodet@gmail.com>
To: dev@felix.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 15, 2010 at 15:05, Felix Meschberger <fmeschbe@gmail.com> wrote=
:
> Hi,
>
> On 15.06.2010 14:49, Guillaume Nodet wrote:
>> What if you change the semantic of a function call without changing the
>> signature ?
>> I guess that's an incompatible change in theory, though still binary
>> compatible. So we can't limit to binary compatibility for versioning imh=
o,
>> 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 <not@apache.org> wrot=
e:
>>
>>> +1 a package version change reflects a change to the package, not a
>>> change to the implementation.
>>>
>>> On 15 June 2010 13:27, Felix Meschberger <fmeschbe@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> On 15.06.2010 14:20, Guillaume Nodet wrote:
>>>>> On Tue, Jun 15, 2010 at 14:15, Felix Meschberger <fmeschbe@gmail.com>
>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 15.06.2010 13:38, Guillaume Nodet wrote:
>>>>>>> Usually, users would use a range, so it should not matter that much=
 I
>>>>>> think.
>>>>>>
>>>>>> Yes and no.
>>>>>>
>>>>>> The problem is, that the bundle version may evolve independently of =
the
>>>>>> API export version.
>>>>>>
>>>>>> Consider for example that we decide to release a 4.0 version of the =
Web
>>>>>> Console in the future whereas the API did not change at all. In this
>>>>>> case, we should still export the API as 3.1 to not break existing
>>>>>> plugins which import the API as [3.1,3.2).
>>>>>>
>>>>>
>>>>> And why would be bump the version if there's no change ?
>>>>
>>>> Where's the change ? The Web Console bundle exports API and contains
>>>> implementation. As such the Web Console bundle attaches a version to t=
he
>>>> exported package and to the bundle itself.
>>>>
>>>> But: We must not mix the semantic of the version of the API export wit=
h
>>>> the semantic of the bundle version, which also includes implementation
>>> code.
>>>>
>>>>> =A0Even 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 (user=
s,
>>>> implementors) of the exported package.
>>>>
>>>> The bundle version on the other hand has semantic meaning to the (huma=
n)
>>>> 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 unhapp=
y
>>>> because we require them to upgrade plugins ...
>>>>
>>>> Granted, if the internal implementation causes the API to change we mu=
st
>>>> increment the version of the exported package.
>>>>
>>>> But in no case should the version of an exported package be incremente=
d
>>>> 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 ?). =A0But even if it is
>>>>> compatible, i'd rather upgrade it to 3.x, because i'd rather have use=
rs
>>> 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 i=
f
>>> 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.co=
m>
>>>>>> 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-05=
3/
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>
>>
>>
>>
>


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