Hi all,
lengthy mail
In comments to SLING-1176 Ian Boston wrote:
"The exports in bundle/api/pom.xml look like they might
become problematic from a support point of view, although
we probably cant avoid this.
[...]
[The problem is the] manual maintenance of the version nu
; lengthy mail
>
> In comments to SLING-1176 Ian Boston wrote:
>
>"The exports in bundle/api/pom.xml look like they might
>become problematic from a support point of view, although
>we probably cant avoid this.
> [...]
> [The problem is the] manual m
Hi,
I tend to agree with Carsten on this one - having per-package OSGi
version numbers makes sense, but without tools to manage that the risk
of making a mess is high.
I would be +1 for having per-package version numbers if there was a
tool to compute/enforce those numbers: using svn to compare
or other bundles; they care for packages to
wire to. And it is the package we are importing and exporting. As such
we have to assign version numbes on the correct level.
Consider this: If we agree on the semantics for version numbers of
exported packages:
* major number change: incompatible API
all. This is not what OSGi is about.
Yes, sure, but I think this is more theory than practice. How likely is
it that the there are two separate implementations, one for the resource
and one for the request package? Only in this case, having different
version numbers matters.
Now, I as I said, ha
ke sense of a myriad
version numbers) is too high. Not because we are too lazy to do it,
but because more work means more room for failure.
As for tooling, something that computes digests on the source code of
packages, and checks that the version numbers change when the
aggregated digests of a given p
On Tue, Nov 17, 2009 at 8:34 AM, Felix Meschberger wrote:
> [...]
> If I change the API in the o.a.s.api.resource package, why would it make
> sense and make lives easier, if I upgrade the minor version number of
> the package o.a.s.api.request, too ? In fact, this makes life even
> harder for th
On Tue, Nov 17, 2009 at 9:51 AM, Vidar Ramdal wrote:
> On Tue, Nov 17, 2009 at 8:34 AM, Felix Meschberger wrote:
>
>> [...]
>> If I change the API in the o.a.s.api.resource package, why would it make
>> sense and make lives easier, if I upgrade the minor version number of
>> the package o.a.s.api
o make sense of a myriad
> version numbers) is too high. Not because we are too lazy to do it,
> but because more work means more room for failure.
>
> As for tooling, something that computes digests on the source code of
> packages, and checks that the version numbers change when t
Hi,
Vidar Ramdal schrieb:
> On Tue, Nov 17, 2009 at 8:34 AM, Felix Meschberger wrote:
>
>> [...]
>> If I change the API in the o.a.s.api.resource package, why would it make
>> sense and make lives easier, if I upgrade the minor version number of
>> the package o.a.s.api.request, too ? In fact, t
g to make sense of a myriad
> version numbers) is too high. Not because we are too lazy to do it,
> but because more work means more room for failure.
>
> As for tooling, something that computes digests on the source code of
> packages, and checks that the version numbers change whe
gt; we have to deploy the new bundle. Why ? Because the resource API was
>> upgraded. Does not make any sense at all. This is not what OSGi is about.
> Yes, sure, but I think this is more theory than practice. How likely is
> it that the there are two separate implementations, one for t
On Tue, Nov 17, 2009 at 10:47, Karl Pauls wrote:
> hence, why not do the following:
>
> version api packages independently along the line of what Felix is suggesting
> version implementation packages based on the bundle version (and
> possibly make importers be hard coupled by using the symbolic-n
Hi,
Alexander Klimetschek schrieb:
> On Tue, Nov 17, 2009 at 10:47, Karl Pauls wrote:
>> hence, why not do the following:
>>
>> version api packages independently along the line of what Felix is suggesting
>> version implementation packages based on the bundle version (and
>> possibly make import
Felix Meschberger wrote:
>
> Well, this is actually handled by the bnd library used by the
> maven-bundle-plugin: This extracts the necessairy versions to create the
> Import-Package statements correctly from the referred to libraries.
>
> So, if you -- as suggested before -- always refer to the
On Tue, Nov 17, 2009 at 11:28 AM, Carsten Ziegeler wrote:
> ...Yes, I think we should give this a try
>
> ...But for most of our bundles this is trivial anyway as we usually have a
> single exported package - the only "beast" is the api bundle, but I
> guess we can manage this one
Ok, so
e2,version 1.0
contains implementation code
* Extend package2 API, thus:
version 1.2.0
exports package1,version 1.1
exports package2,version 1.2
contains implementation code
Note, there will not be a package2 version 1.1 but the version numbers
remain aligned and the version nu
On Tue, Nov 17, 2009 at 1:17 PM, Felix Meschberger wrote:
> ...How about this:
>
> * The bundle version number is always >= the highest version
> number of all exported packages.
> * If only implementation fixes apply to a bundle, the micro
> number is increased
> * If the version number is to b
Hi,
Bertrand Delacretaz schrieb:
> On Tue, Nov 17, 2009 at 1:17 PM, Felix Meschberger wrote:
>> ...How about this:
>>
>> * The bundle version number is always >= the highest version
>> number of all exported packages.
>> * If only implementation fixes apply to a bundle, the micro
>> number is i
On Tue, Nov 17, 2009 at 13:28, Felix Meschberger wrote:
> Hi,
>
> Bertrand Delacretaz schrieb:
>> On Tue, Nov 17, 2009 at 1:17 PM, Felix Meschberger
>> wrote:
>>> ...How about this:
>>>
>>> * The bundle version number is always >= the highest version
>>> number of all exported packages.
>>> * I
ge within
a single bundle and the rate of version number change of the bundle
itself will accelerate (sort of positive feedback). Over time I think
this will lead to confusion since there could be many missing versions
of each package and a highly complex bundle version history.
Incr
e of the bundle itself
> will accelerate (sort of positive feedback). Over time I think this will
> lead to confusion since there could be many missing versions of each package
> and a highly complex bundle version history.
>
> Incrementing of package version numbers without holes in t
On Tue, Nov 17, 2009 at 1:48 PM, Alexander Klimetschek wrote:
> That sounds good to me. That way one could ignore the package versions
> if he likes to (I know you shouldn't, but it's more natural for people
> new to osgi).
>
> +1 for "testing it" with the sling api bundle.
Testing sounds good, b
On Tue, Nov 17, 2009 at 3:45 PM, Vidar Ramdal wrote:
> ...Running two different schemes - one for Sling API, and one for the
> other bundles - could easily add to the confusion, I suspect
Not necessarily IMHO...the API and implementation bundles are slightly
different beasts.
-Bertrand
gt; single bundle and the rate of version number change of the bundle itself
>> will accelerate (sort of positive feedback). Over time I think this will
>> lead to confusion since there could be many missing versions of each package
>> and a highly complex bundle version history.
&g
Hi,
Vidar Ramdal schrieb:
> On Tue, Nov 17, 2009 at 1:48 PM, Alexander Klimetschek
> wrote:
>> That sounds good to me. That way one could ignore the package versions
>> if he likes to (I know you shouldn't, but it's more natural for people
>> new to osgi).
>>
>> +1 for "testing it" with the slin
ill not modify all bundles right away. Rather I would say
> we modify bundles as we are ready to release them and there is a
> modification underway anyway
I would like us to vote on this, before we go any further than the api
bundle experiment that we seem to agree on based on this thread.
T
Ok, I am done for now with the page [1]. Over the course of an hour or
two, it should also be synchronized to the site.
Note, that I still kept the unsynchronized version numbers because in
practice the best we can do is apply the same semantics to package and
bundle versions when it comes to
api
> bundle experiment that we seem to agree on based on this thread.
>
> The impact of this change in version numbers management is high enough
> to warrant a formal vote, IMHO.
Makes sense. Also because I named this thing a "Version Policy", it
implies a vote will be held. For now I added a comment to indicate, this
is just a proposal.
Regards
Felix
the filesystem resource provider exists for a long time and is very useful.
until version 1.1.4 it supported only the "old" Sling Resource Provider SPI.
in version 1.2.0 it was switched to the new Resource Provider SPI. this was an
backwards incompatible change because one of the osgi config pro
Hi,
On Tue, Feb 28, 2017 at 5:45 PM, Stefan Seifert wrote:
> ...the drawback of this proposal is that we have a few older releases in the
> 1.x
> line (1.2.0 and 1.2.2) that are not in line with semantic versioning, but
> this would be
> fixed in 1.3.0 and upwards...
I think that's reasonable.
>How do you intend to manage both branches of the fork? svn branches?
>Maybe creating a new "legacy" Maven module for one of them would be
>clearer.
the plan was to use a svn branch for the "old SPI": [1]
release would then be done both on the trunk (2.x) and this branch (1.x)
versions.
we are
On Wed, Mar 1, 2017 at 2:54 PM, Stefan Seifert wrote:
> ...the plan was to use a svn branch for the "old SPI": [1] ...
>
> ...we are doing this already like this for the parallel maintenance of
> osgi-mock and sling-mock 1.x / 2.x. [2] and it works quite well...
Ok, I wasn't aware of that - work
33 matches
Mail list logo
