You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by zoe slattery <zo...@gmail.com> on 2011/02/04 19:50:25 UTC
Versions (leading on from releases discussions)
Hi - I had a very useful IRC discussion with Guillaume trying to make
sure that we had a common understanding of the versioning policy that is
used in Aries today and the implications of changing it to use OSGi
semantic versioning for packages, and maybe for bundles.
I believe we agreed that we do not use package versioning correctly at
the moment and, in order to do so, we would have to break the way that
that package versions are derived from bundle versions and manage
package versions independently (manually).
We didn't agree on the right thing to do with bundle versions (we didn't
disagree either, I just don't know what the right answer is) , in
particular where a module has a set of sub-modules (bundles). The
options are either:
1) To agree not to follow bundle versioning policy. So all teh
submodules in a module would have teh same bundle version irrespective
of whether they have changed.
2) To follow it and try and cope with what could become an unholy mess
of bundle versions in the development code base.
I tried to draw this out in a set of charts, here:
https://svn.apache.org/repos/asf/aries/slides/aries-version.odp, and
I've just realised that not everyone will have odp so I'll put a pdf in
there too.
These are for discussion and illustration of the problem - feed back
welcome.
Zoe
Re: Versions (leading on from releases discussions)
Posted by zoe slattery <zo...@gmail.com>.
On 04/02/2011 19:19, Guillaume Nodet wrote:
> Just one question. On your slides do you imply that the package
> versions are the same than the bundle version ? It seems to be the
> case.
No, well not intentionally. What I meant to say is that they are the
same at the moment but that they should not be - and step one is to
break the coupling between them.
Slide 1 shows them the same (as they are the way we build at the
moment), Slide 3 and thereafter they are different.
> On Fri, Feb 4, 2011 at 19:50, zoe slattery<zo...@gmail.com> wrote:
>> Hi - I had a very useful IRC discussion with Guillaume trying to make sure
>> that we had a common understanding of the versioning policy that is used in
>> Aries today and the implications of changing it to use OSGi semantic
>> versioning for packages, and maybe for bundles.
>>
>> I believe we agreed that we do not use package versioning correctly at the
>> moment and, in order to do so, we would have to break the way that that
>> package versions are derived from bundle versions and manage package
>> versions independently (manually).
>>
>> We didn't agree on the right thing to do with bundle versions (we didn't
>> disagree either, I just don't know what the right answer is) , in particular
>> where a module has a set of sub-modules (bundles). The options are either:
>>
>> 1) To agree not to follow bundle versioning policy. So all teh submodules
>> in a module would have teh same bundle version irrespective of whether they
>> have changed.
>> 2) To follow it and try and cope with what could become an unholy mess of
>> bundle versions in the development code base.
>>
>> I tried to draw this out in a set of charts, here:
>> https://svn.apache.org/repos/asf/aries/slides/aries-version.odp, and I've
>> just realised that not everyone will have odp so I'll put a pdf in there
>> too.
>>
>> These are for discussion and illustration of the problem - feed back
>> welcome.
>>
>>
>> Zoe
>>
>>
>>
>
>
Re: Versions (leading on from releases discussions)
Posted by Guillaume Nodet <gn...@gmail.com>.
Just one question. On your slides do you imply that the package
versions are the same than the bundle version ? It seems to be the
case.
On Fri, Feb 4, 2011 at 19:50, zoe slattery <zo...@gmail.com> wrote:
> Hi - I had a very useful IRC discussion with Guillaume trying to make sure
> that we had a common understanding of the versioning policy that is used in
> Aries today and the implications of changing it to use OSGi semantic
> versioning for packages, and maybe for bundles.
>
> I believe we agreed that we do not use package versioning correctly at the
> moment and, in order to do so, we would have to break the way that that
> package versions are derived from bundle versions and manage package
> versions independently (manually).
>
> We didn't agree on the right thing to do with bundle versions (we didn't
> disagree either, I just don't know what the right answer is) , in particular
> where a module has a set of sub-modules (bundles). The options are either:
>
> 1) To agree not to follow bundle versioning policy. So all teh submodules
> in a module would have teh same bundle version irrespective of whether they
> have changed.
> 2) To follow it and try and cope with what could become an unholy mess of
> bundle versions in the development code base.
>
> I tried to draw this out in a set of charts, here:
> https://svn.apache.org/repos/asf/aries/slides/aries-version.odp, and I've
> just realised that not everyone will have odp so I'll put a pdf in there
> too.
>
> These are for discussion and illustration of the problem - feed back
> welcome.
>
>
> Zoe
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Versions (leading on from releases discussions)
Posted by Guillaume Nodet <gn...@gmail.com>.
I don't that this way of doing things is scalable enough, but that may
be just me.
Or it could if we have much more coarse grained bundles that we
currently do (for example, just keep the uber bundles and move
everything else as plain jars).
On Fri, Feb 4, 2011 at 23:30, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> To me bundle versions are for targetted at humans: They convey the
> evolution of the bundle as a whole:
>
> * Increment the micro version if you fix a bug
> * Increment the minor version if you add functionality
> * Increment the major version if you potentially break
> backwards compatibility or added the next revolution.
>
> To the OSGi framework the bundle version is basically irrelevant (unless
> you use the dreaded Require-Bundle ...) [well not really, but sort of].
>
> I think the only real requirement I would place on bundle version
> numbers is to not release (and thus increase the version number) if
> there is no change. So there should not be a version x and a version y,
> where x != y, of a bundle B which are identical. This is confusing.
>
> As for packages: version numbers of exported packages IMO and according
> to the OSGi semantic versioning whitepaper convey about the contract of
> the package. As such package versions are almost never the same as
> bundle versions (well, maybe they are equal in the first release....).
>
> Like bundle versions, package versions should not be changed if there is
> no change in the package. This would not only be confusing but only be
> detriment to configuring system.
>
> So, my advice is to version packages and bundles independently according
> to the needs bundle development. Don't try to keep versions in sync.
> This will not work.
>
> At the end of the day un-equal version numbers are a matter of life (or
> do you sync with XML APIs, Lucene, Derby, JTA API, etc... ?). Over time
> you will get used to different version numbers and it will be natural.
>
> Actually, what you gain be not requiring synced version numbers if
> increased freedom in evolving bundles: some bundles are more stable than
> others. So be it and enjoy this situation ;-)
>
> Regards
> Felix
>
> Am Freitag, den 04.02.2011, 18:50 +0000 schrieb zoe slattery:
>> Hi - I had a very useful IRC discussion with Guillaume trying to make
>> sure that we had a common understanding of the versioning policy that is
>> used in Aries today and the implications of changing it to use OSGi
>> semantic versioning for packages, and maybe for bundles.
>>
>> I believe we agreed that we do not use package versioning correctly at
>> the moment and, in order to do so, we would have to break the way that
>> that package versions are derived from bundle versions and manage
>> package versions independently (manually).
>>
>> We didn't agree on the right thing to do with bundle versions (we didn't
>> disagree either, I just don't know what the right answer is) , in
>> particular where a module has a set of sub-modules (bundles). The
>> options are either:
>>
>> 1) To agree not to follow bundle versioning policy. So all teh
>> submodules in a module would have teh same bundle version irrespective
>> of whether they have changed.
>> 2) To follow it and try and cope with what could become an unholy mess
>> of bundle versions in the development code base.
>>
>> I tried to draw this out in a set of charts, here:
>> https://svn.apache.org/repos/asf/aries/slides/aries-version.odp, and
>> I've just realised that not everyone will have odp so I'll put a pdf in
>> there too.
>>
>> These are for discussion and illustration of the problem - feed back
>> welcome.
>>
>>
>> Zoe
>>
>>
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Versions (leading on from releases discussions)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
To me bundle versions are for targetted at humans: They convey the
evolution of the bundle as a whole:
* Increment the micro version if you fix a bug
* Increment the minor version if you add functionality
* Increment the major version if you potentially break
backwards compatibility or added the next revolution.
To the OSGi framework the bundle version is basically irrelevant (unless
you use the dreaded Require-Bundle ...) [well not really, but sort of].
I think the only real requirement I would place on bundle version
numbers is to not release (and thus increase the version number) if
there is no change. So there should not be a version x and a version y,
where x != y, of a bundle B which are identical. This is confusing.
As for packages: version numbers of exported packages IMO and according
to the OSGi semantic versioning whitepaper convey about the contract of
the package. As such package versions are almost never the same as
bundle versions (well, maybe they are equal in the first release....).
Like bundle versions, package versions should not be changed if there is
no change in the package. This would not only be confusing but only be
detriment to configuring system.
So, my advice is to version packages and bundles independently according
to the needs bundle development. Don't try to keep versions in sync.
This will not work.
At the end of the day un-equal version numbers are a matter of life (or
do you sync with XML APIs, Lucene, Derby, JTA API, etc... ?). Over time
you will get used to different version numbers and it will be natural.
Actually, what you gain be not requiring synced version numbers if
increased freedom in evolving bundles: some bundles are more stable than
others. So be it and enjoy this situation ;-)
Regards
Felix
Am Freitag, den 04.02.2011, 18:50 +0000 schrieb zoe slattery:
> Hi - I had a very useful IRC discussion with Guillaume trying to make
> sure that we had a common understanding of the versioning policy that is
> used in Aries today and the implications of changing it to use OSGi
> semantic versioning for packages, and maybe for bundles.
>
> I believe we agreed that we do not use package versioning correctly at
> the moment and, in order to do so, we would have to break the way that
> that package versions are derived from bundle versions and manage
> package versions independently (manually).
>
> We didn't agree on the right thing to do with bundle versions (we didn't
> disagree either, I just don't know what the right answer is) , in
> particular where a module has a set of sub-modules (bundles). The
> options are either:
>
> 1) To agree not to follow bundle versioning policy. So all teh
> submodules in a module would have teh same bundle version irrespective
> of whether they have changed.
> 2) To follow it and try and cope with what could become an unholy mess
> of bundle versions in the development code base.
>
> I tried to draw this out in a set of charts, here:
> https://svn.apache.org/repos/asf/aries/slides/aries-version.odp, and
> I've just realised that not everyone will have odp so I'll put a pdf in
> there too.
>
> These are for discussion and illustration of the problem - feed back
> welcome.
>
>
> Zoe
>
>
Re: Versions (leading on from releases discussions)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Freitag, den 04.02.2011, 20:12 +0100 schrieb Guillaume Nodet:
> Thanks Zoe. One thing that may help is derived from Graham suggestion.
> I think it should be possible to have a maven plugin that verify that
> the semantics
> of our package versioning is correct by comparing the current package
> and its version
> with the previous release one. If we can do so, a small step further
> would be to
> eventually let the plugin decide when and how to increment the version
> for each package...
I am sure lots of people would love such a plugin !
Well, basically API comparison code is available but AFAICT mostly
around reporting not in this direction.
Regards
Felix
>
> On Fri, Feb 4, 2011 at 19:50, zoe slattery <zo...@gmail.com> wrote:
> > Hi - I had a very useful IRC discussion with Guillaume trying to make sure
> > that we had a common understanding of the versioning policy that is used in
> > Aries today and the implications of changing it to use OSGi semantic
> > versioning for packages, and maybe for bundles.
> >
> > I believe we agreed that we do not use package versioning correctly at the
> > moment and, in order to do so, we would have to break the way that that
> > package versions are derived from bundle versions and manage package
> > versions independently (manually).
> >
> > We didn't agree on the right thing to do with bundle versions (we didn't
> > disagree either, I just don't know what the right answer is) , in particular
> > where a module has a set of sub-modules (bundles). The options are either:
> >
> > 1) To agree not to follow bundle versioning policy. So all teh submodules
> > in a module would have teh same bundle version irrespective of whether they
> > have changed.
> > 2) To follow it and try and cope with what could become an unholy mess of
> > bundle versions in the development code base.
> >
> > I tried to draw this out in a set of charts, here:
> > https://svn.apache.org/repos/asf/aries/slides/aries-version.odp, and I've
> > just realised that not everyone will have odp so I'll put a pdf in there
> > too.
> >
> > These are for discussion and illustration of the problem - feed back
> > welcome.
> >
> >
> > Zoe
> >
> >
> >
>
>
>
Re: Versions (leading on from releases discussions)
Posted by Guillaume Nodet <gn...@gmail.com>.
Thanks Zoe. One thing that may help is derived from Graham suggestion.
I think it should be possible to have a maven plugin that verify that
the semantics
of our package versioning is correct by comparing the current package
and its version
with the previous release one. If we can do so, a small step further
would be to
eventually let the plugin decide when and how to increment the version
for each package...
On Fri, Feb 4, 2011 at 19:50, zoe slattery <zo...@gmail.com> wrote:
> Hi - I had a very useful IRC discussion with Guillaume trying to make sure
> that we had a common understanding of the versioning policy that is used in
> Aries today and the implications of changing it to use OSGi semantic
> versioning for packages, and maybe for bundles.
>
> I believe we agreed that we do not use package versioning correctly at the
> moment and, in order to do so, we would have to break the way that that
> package versions are derived from bundle versions and manage package
> versions independently (manually).
>
> We didn't agree on the right thing to do with bundle versions (we didn't
> disagree either, I just don't know what the right answer is) , in particular
> where a module has a set of sub-modules (bundles). The options are either:
>
> 1) To agree not to follow bundle versioning policy. So all teh submodules
> in a module would have teh same bundle version irrespective of whether they
> have changed.
> 2) To follow it and try and cope with what could become an unholy mess of
> bundle versions in the development code base.
>
> I tried to draw this out in a set of charts, here:
> https://svn.apache.org/repos/asf/aries/slides/aries-version.odp, and I've
> just realised that not everyone will have odp so I'll put a pdf in there
> too.
>
> These are for discussion and illustration of the problem - feed back
> welcome.
>
>
> Zoe
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com