Hi
As of now, we don’t have an official branch policy. In fact we had a discussion
before and we decided against such.
So I would think that we should continue releasing from trunk and from trunk
only.
As such I like Tom’s proposal for a R-Next working branch. And since OSGi
generally release
My preference would be to do new osgi R-Next work in a dedicated feature
branch instead of directly in trunk. That way trunk remains releasable at
all times. But if we want to instead branch each project when its trunk
version becomes unreleasable then I guess that is fine, but it does seem
confu
I understand that the OSGi alliance would not release an unfinished spec .. but
I think it would not need to.
What I propose instead is that the alliance develops specs like we develop open
source software. The spec could be defined in a maven project on github.
There would be a daily build of
Thomas Watson wrote
> This has come to my attention because I am working on some fixes in the SCR
> implementation. I noticed the latest SCR in trunk now depends on
> org.apache.felix.configadmin 1.9.0-SNAPSHOT. And I think
> org.apache.felix.configadmin 1.9.0 is being used to implement OSGi R7.
This has come to my attention because I am working on some fixes in the SCR
implementation. I noticed the latest SCR in trunk now depends on
org.apache.felix.configadmin 1.9.0-SNAPSHOT. And I think
org.apache.felix.configadmin 1.9.0 is being used to implement OSGi R7. So
now we have OSGi R7 API
Hi Tom,
My proposal here only applies to implementations of entirely new specs.
Updates on existing specs are not covered, hence the point around versions
<1.
I completely agree that updates to existing specs should be done on a
branch to keep trunk releasable.
Cheers,
David
On 3 January 2017
Why do OSGi R-next work directly in trunk where I would expect releases
could be done at any time. It seems to me that trunk should remain
'releasable'. It would be much more simple to do OSGi R-next work in a
dedicated branch where you have the freedom to put interim OSGi APIs
assuming we would
On 1/3/17 11:59 , David Bosschaert wrote:
Hi Felix and Richard,
On 3 January 2017 at 16:40, Richard S. Hall wrote:
On 1/3/17 11:21 , Felix Meschberger wrote:
Hi
Upfront I like the amended proposal of using a version < 1 and a
mandatory attribute „provisional“ with value „felix“. As Neil s
Hi Felix and Richard,
On 3 January 2017 at 16:40, Richard S. Hall wrote:
>
> On 1/3/17 11:21 , Felix Meschberger wrote:
>
>> Hi
>>
>> Upfront I like the amended proposal of using a version < 1 and a
>> mandatory attribute „provisional“ with value „felix“. As Neil said, BND
>> will solve this for
On 1/3/17 11:21 , Felix Meschberger wrote:
Hi
Upfront I like the amended proposal of using a version < 1 and a mandatory
attribute „provisional“ with value „felix“. As Neil said, BND will solve this for
imports be it the bndtools or the maven bundle plugin.
Not declaring a version and thus u
Hi
Upfront I like the amended proposal of using a version < 1 and a mandatory
attribute „provisional“ with value „felix“. As Neil said, BND will solve this
for imports be it the bndtools or the maven bundle plugin.
Not declaring a version and thus using 0.0.0 will have BND generate a
version-l
Hi Christian,
On 3 January 2017 at 10:00, Christian Schneider
wrote:
>
>> Why do we need the mandatory provisional attribute? With the version < 1
> we already ensure that we have a clean cut when the
> final API is released.
>
> I think this extra protection only makes it harder to use the API.
On 03.01.2017 10:46, David Bosschaert wrote:
Hi Richard,
On 23 December 2016 at 19:19, Richard S. Hall wrote:
I'm not for changing the policy. The whole point behind the policy is that
anything that we released is in some way blessed and lives forever. If we
release packages in the OSGi names
Hi Richard,
On 23 December 2016 at 19:19, Richard S. Hall wrote:
> I'm not for changing the policy. The whole point behind the policy is that
> anything that we released is in some way blessed and lives forever. If we
> release packages in the OSGi namespace, they look official even potentially
I fully support this proposal. The major change on release of the API
should make sure that we do not get problems when there are changes.
As the package name stays the same it will still be easy for users to
migrate.
I also hope the OSGi alliance makes the newest API snapshot available in
maven a
+1
Good point !
Regards
JB
On 12/23/2016 05:54 PM, Raymond Auge wrote:
+1
I'd really like this support as well. As an RI writer the prospect of
having to use a different package name during the API development process
is not appealing at all.
- Ray
On Fri, Dec 23, 2016 at 8:01 AM, Bram Pouw
I'm not for changing the policy. The whole point behind the policy is
that anything that we released is in some way blessed and lives forever.
If we release packages in the OSGi namespace, they look official even
potentially after the OSGi Alliance dumps an RFC (ala Gogo). There is no
way for u
+1
I'd really like this support as well. As an RI writer the prospect of
having to use a different package name during the API development process
is not appealing at all.
- Ray
On Fri, Dec 23, 2016 at 8:01 AM, Bram Pouwelse wrote:
> I Like the simple version ( org.osgi.someapi; version="0.1";
I Like the simple version ( org.osgi.someapi; version="0.1";
mandatory:="provisional"; provisional="felix" ), and then I think it makes
sense to advise a bit more conservative import range like
Import-Package: org.osgi.someapi;version="[0.1,0.2)";provisional=felix
And that also implies that the v
> On 23 Dec 2016, at 13:36, David Bosschaert wrote:
>
> Hi all,
>
> On 23 December 2016 at 12:13, Jan Willem Janssen <
> janwillem.jans...@luminis.eu> wrote:
>
>>
>>> On 23 Dec 2016, at 12:30, David Bosschaert
>> wrote:
>>>
>>> Hi Bram,
>>>
>>> On 23 December 2016 at 11:02, Bram Pouwelse
This suggestion from David sounds like a reasonable compromise to me.
I would point out that if you are building with bnd and you put a bundle with a
mandatory attribute on your build path, then bnd will assume that you want to
set that attribute on your import. Thus it will work fairly transpar
Hi all,
On 23 December 2016 at 12:13, Jan Willem Janssen <
janwillem.jans...@luminis.eu> wrote:
>
> > On 23 Dec 2016, at 12:30, David Bosschaert
> wrote:
> >
> > Hi Bram,
> >
> > On 23 December 2016 at 11:02, Bram Pouwelse wrote:
> >
> >>> I think it would be nice if we could relax the policy a
> On 23 Dec 2016, at 12:30, David Bosschaert wrote:
>
> Hi Bram,
>
> On 23 December 2016 at 11:02, Bram Pouwelse wrote:
>
>>> I think it would be nice if we could relax the policy at [1] a little bit
>> and say that it is ok to release bundles with provisional API in versions <
>> 1.0. The OS
In that case I don't like the idea of released bundles using API versions <
1. What if some other bundle is providing that same package there would be
no way for te resolver to know that those packages are actually not
compatible.
On Fri, Dec 23, 2016 at 12:30 PM David Bosschaert <
david.bosscha..
Hi Bram,
On 23 December 2016 at 11:02, Bram Pouwelse wrote:
> > I think it would be nice if we could relax the policy at [1] a little bit
> and say that it is ok to release bundles with provisional API in versions <
> 1.0. The OSGi APIs always start their versions at 1.0 so an API version 0.2
>
> I think it would be nice if we could relax the policy at [1] a little bit
and say that it is ok to release bundles with provisional API in versions <
1.0. The OSGi APIs always start their versions at 1.0 so an API version 0.2
will never conflict with an OSGi released API.
That sounds nice but yo
26 matches
Mail list logo
