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 11:47:32 UTC
[VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf 1.6.2
(2nd try)
I would like to call a new vote on the following subproject releases:
webconsole 3.1.0
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)
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf
1.6.2 (2nd try)
Posted by Alasdair Nottingham <no...@apache.org>.
+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 <fm...@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: [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: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 <fm...@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)
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
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 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 ? 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).
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 <fm...@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)
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
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 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).
> 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 <fm...@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)
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf
1.6.2 (2nd try)
Posted by Guillaume Nodet <gn...@gmail.com>.
Usually, users would use a range, so it should not matter that much I think.
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.
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 <fm...@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)
> >>>
> >>
> >
> >
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
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 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 <fm...@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)
>>>
>>
>
>
>
Re: [VOTE] Release webconsole 3.1.0 bundlerepository 1.6.4, karaf
1.6.2 (2nd try)
Posted by Guillaume Nodet <gn...@gmail.com>.
Wow, I was expecting the package to be derived from the project version.
I'll fix that now.
Cancelling this release again. ...
On Tue, Jun 15, 2010 at 12:46, Felix Meschberger <fm...@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)
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
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 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)
>