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/09 18:33:02 UTC
[DISCUSS] Release process
Hi
I started to pull together both the requirements, information about what
we do already, extracts from some discussion on the mailing lists and
assemble them into a web page. The page is here
http://aries.apache.org/development/ReleaseProcessRequirements.html
I used a web page because I was having difficulty writing it down
without diagrams, so I thought we needed something with pictures.
I have not attempted to reach any conclusion - I've just tried to list
advantages and disadvantages as clearly as I can.
I would like to discuss the content of the page on this mailing list,
principally I would like to understand what advantages and disadvantages
I have missed in each case. I will update the page based on feedback on
this list. Eventually, the web page should reflect a consensus on what
the advantages and disadvantages are in each case.
If anything isn't clear (and I suspect it won't be) please let me know.
Zoe
Re: [DISCUSS] Release process
Posted by zoe slattery <zo...@gmail.com>.
On 09/02/2011 18:55, Guillaume Nodet wrote:
> Fair point. I missed that quote, which doesn't seem to imply that
> require bundle is far from a best practice ...
:-) That is also a good point.
> On Wed, Feb 9, 2011 at 19:45, zoe slattery<zo...@gmail.com> wrote:
>> Hi
>>> Throughout the web page, you refer to "semantic versioning of
>>> bundles", but afaik, there's no such thing.
>> This is a quote from the OSGi semantic versioning white paper:
>>
>> "Requiring another bundle is similar to a short form of importing all the
>> exported packages of that required bundle. The version of a bundle must
>> therefore semantically aggregate the semantics of all its constituent
>> packages. If any of these packages is incompatible with its providers then
>> the bundle version must increment the minor version. If any of these
>> packages is incompatible with consumers, the bundle version must increment
>> the major version. It is clear, that on average, the version of a bundle
>> will be much more volatile than the versions of its constituent packages,
>> increasing the dependency problems."
>>
>> This indicated to me that bundles are semantically versioned.
>>
>> Zoe
>>
>
>
Re: [DISCUSS] Release process
Posted by Guillaume Nodet <gn...@gmail.com>.
In "Disadvantages of the release by module process" :
#1 what do you imply here ? We can't release the same bundle with the
exact same version I think. This would mean we'd have to at least
change the micro version or the qualifier (but preferably the micro
version), even if the content hasn't changed.
#3 I guess you made some tests in your branch. so mavne can't cope
with blueprint-core 1.0.1-SNAPSHOT and blueprint-cm 1.0.3-SNAPSHOT in
the same build. Or rather, maven can, but the release plugin can't,
right ? If so and if that can't be easily change, it kinda forbid
this option imho.
#4 i think this is a consequence of applying the semantic versioning
at the bundle level and I don't see any nice way to solve that
In the "Disadvantages of releasing by bundle"
#2 svn: Sling uses a single tree, which makes branching very difficult
#3: i think if we apply at the package level the rule we talked about,
i.e. each change which is not a pure bug fix lead to a minor version
bump (from 1.3.2 to 1.4.0 for example), this would reflect at the
bundle level, so it should be possible to maintain correct branches
per bundle
I'd add:
#4 there is no way to ensure a coherent (meaning to artifact is
needed twice) set of bundles is sufficient (granted OSGi can easily
cope with that, but it's kind ugly, and from a maven perspective, very
difficult to deal with as maven does not allow having two dependencies
with different versions in the same build)
If the release by bundle would be favored, I wonder if we should
follow more closely the felix model, where usually a bundle has very
few dependencies, i.e. it embeds the API (export + import pacakge) and
the implementation. This would have the following advantages:
# we'd roughly combine "release per component" and "release per bundle"
# all disadvantages listed in "release per bundle" would go away
# we'd still have all the advantages of "release per bundle" and
"release per module"
The release process would be much simplier, consumption much simplier too.
Another way, if we don't want to keep a clean organization in several
maven projects, would be to have each maven project generate a jar,
and only put the metadata on the bundle for the whole component.
On Wed, Feb 9, 2011 at 19:55, Guillaume Nodet <gn...@gmail.com> wrote:
> Fair point. I missed that quote, which doesn't seem to imply that
> require bundle is far from a best practice ...
>
> On Wed, Feb 9, 2011 at 19:45, zoe slattery <zo...@gmail.com> wrote:
>> Hi
>>>
>>> Throughout the web page, you refer to "semantic versioning of
>>> bundles", but afaik, there's no such thing.
>>
>> This is a quote from the OSGi semantic versioning white paper:
>>
>> "Requiring another bundle is similar to a short form of importing all the
>> exported packages of that required bundle. The version of a bundle must
>> therefore semantically aggregate the semantics of all its constituent
>> packages. If any of these packages is incompatible with its providers then
>> the bundle version must increment the minor version. If any of these
>> packages is incompatible with consumers, the bundle version must increment
>> the major version. It is clear, that on average, the version of a bundle
>> will be much more volatile than the versions of its constituent packages,
>> increasing the dependency problems."
>>
>> This indicated to me that bundles are semantically versioned.
>>
>> Zoe
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Release process
Posted by Graham Charters <gc...@gmail.com>.
On 11 February 2011 12:07, Guillaume Nodet <gn...@gmail.com> wrote:
> That makes me think that we don't necessarily have to tie the maven
> version to the Bundle-Version, which would remove the problem Zoe
> mentioned with the release plugin.
> So we could release per component (i.e. a bunch of bundles together),
> where all bundles would have a maven version of 0.4.0, but the
> Bundle-Version would evolve separately.
>
Would that mean we potentially end up releasing an identical bundle
multiple times? Also, would we end up with the release version in the
artifact name and location in the repo for something that has a
different bundle version? I think that would be very confusing, but
if we can fix that then it's a possibility.
> The bundle semantic versioning service is actually open source, so we
> could integrate it into maven-bundle-plugin (or anywhere else). The
> problem is that there are cases where a purely semantic change (i.e.
> you change a service implementation in an incompatible way without
> changing the API) can't be find by such a tool, as it can only work at
> the API (class / method) level I think.
>
Yes, you're right. The tool will work the majority of times as I
would assume we typically won't want to change the semantics of
existing APIs, but if/when we do, then we'll need some way to drive a
manually specified version.
> On Fri, Feb 11, 2011 at 11:55, Graham Charters <gc...@gmail.com> wrote:
>> Zoe,
>>
>> Thanks for doing this great piece of work, and presenting the options so well.
>>
>> Personally, I feel, as an enterprise OSGi programming model project,
>> we need to be practicing what OSGi preaches. If there are problems
>> associated with that, then it would be good if we could feed that back
>> into OSGi, or try to fix/improve the processes. We're not the only
>> ones to be going down this path.
>>
>> There are well-documented reasons why separating API from
>> implementation is generally a good thing. If we can preserve that, I
>> think it would be great. Granted, this results in more modules, which
>> will complicate the release process and perhaps make management
>> harder. Zoe mentioned 'profiles'. Maybe there are roll-up
>> distributions we could build targeted at different types of consumer
>> (e.g. full aries, blueprint, application, etc). I'd like to think we
>> could also address the uber-bundle use case with distributions and
>> subsystem (a little raw at the moment), as we've discussed in the
>> past.
>>
>> I think the semantic versioning tool that Zoe was referring to is
>> described in this presentation:
>> http://www.osgi.org/wiki/uploads/CommunityEvent2010/OSGi%20Community%202010%20-%20Brada.pdf
>> . It's described as "prototype", but that was a little while ago and
>> it might be worth a try.
>>
>> Just my 2 pence.
>>
>> Regards, Graham.
>>
>> On 10 February 2011 07:20, Guillaume Nodet <gn...@gmail.com> wrote:
>>> On Wed, Feb 9, 2011 at 21:06, zoe slattery <zo...@gmail.com> wrote:
>>>> On 09/02/2011 19:26, Guillaume Nodet wrote:
>>>>>
>>>>> In "Disadvantages of the release by module process" :
>>>>>
>>>>> #1 what do you imply here ? We can't release the same bundle with the
>>>>> exact same version I think. This would mean we'd have to at least
>>>>> change the micro version or the qualifier (but preferably the micro
>>>>> version), even if the content hasn't changed.
>>>>
>>>> That's a good question. I can't actually find any ruling that says that we
>>>> can't release the same thing twice, so it would come down to a view about
>>>> whether it was better to release the same thing twice with the same name, or
>>>> the same thing twice with a different name.
>>>
>>> Maven central will refuse to deploy if one tries to upload another
>>> copy of the same artifact / version afaik.
>>> Also a release, once voted should be immutable imho.
>>>
>>>>>
>>>>> #3 I guess you made some tests in your branch. so mavne can't cope
>>>>> with blueprint-core 1.0.1-SNAPSHOT and blueprint-cm 1.0.3-SNAPSHOT in
>>>>> the same build. Or rather, maven can, but the release plugin can't,
>>>>> right ? If so and if that can't be easily change, it kinda forbid
>>>>> this option imho.
>>>>
>>>> Yes - that's what I was doing in the branch. And personally I agree with
>>>> your conclusion.
>>>>>
>>>>> #4 i think this is a consequence of applying the semantic versioning
>>>>> at the bundle level and I don't see any nice way to solve that
>>>>
>>>> Indeed.
>>>>>
>>>>> In the "Disadvantages of releasing by bundle"
>>>>> #2 svn: Sling uses a single tree, which makes branching very difficult
>>>>> #3: i think if we apply at the package level the rule we talked about,
>>>>> i.e. each change which is not a pure bug fix lead to a minor version
>>>>> bump (from 1.3.2 to 1.4.0 for example), this would reflect at the
>>>>> bundle level, so it should be possible to maintain correct branches
>>>>> per bundle
>>>>
>>>> That would help, but there is a lot of personal judgement in making that
>>>> decision. I wonder if we should look at the versioning
>>>> tooling in Ace (I think Felix (?) posted a link to it earlier). I read a bit
>>>> about it but have not actually tried it.
>>>
>>> Yes, we can't have any hard rule on that, though we could see it in a
>>> different way. Any change that does not ugrade the minor version
>>> should be backported to all previous branches. I think it's closer to
>>> the usual development model, but lead to the same conclusion.
>>>
>>> Not sure what you're referring to for the tooling. Any pointer ?
>>>
>>>>>
>>>>> I'd add:
>>>>> #4 there is no way to ensure a coherent (meaning to artifact is
>>>>> needed twice) set of bundles is sufficient (granted OSGi can easily
>>>>> cope with that, but it's kind ugly, and from a maven perspective, very
>>>>> difficult to deal with as maven does not allow having two dependencies
>>>>> with different versions in the same build)
>>>>
>>>> I'm not totally sure that I understand you here. Do you mean 'a set of
>>>> bundles that we know all work together', like for example the blueprint
>>>> bundles?
>>>> If so, I had thought about maybe having something like a 'profile' -
>>>> basically a pom which would assemble a set of bundles and their source (?)
>>>> so a user would just download the pom.xml and run it to assemble something
>>>> like what we release in the Blueprint (for example) module.
>>>
>>> Let's say we have blueprint-core depends on utils [1,2) and
>>> transaction-blueprint depends on utils [2,3) at some point in time.
>>> There's no way to have maven capture such dependencies if you build
>>> something that depends on both blueprint-core and
>>> transaction-blueprint.
>>> It's also much less convenient for users when you need to know what to install.
>>>
>>>>>
>>>>> If the release by bundle would be favored, I wonder if we should
>>>>> follow more closely the felix model, where usually a bundle has very
>>>>> few dependencies, i.e. it embeds the API (export + import pacakge) and
>>>>> the implementation. This would have the following advantages:
>>>>> # we'd roughly combine "release per component" and "release per bundle"
>>>>> # all disadvantages listed in "release per bundle" would go away
>>>>> # we'd still have all the advantages of "release per bundle" and
>>>>> "release per module"
>>>>> The release process would be much simplier, consumption much simplier too.
>>>>
>>>> It's a thought. Do you really mean that we would abandon everything except
>>>> the uber-bundles? Or have I misunderstood?
>>>
>>> That's a suggestion yes. It's a granularity problem. The finer we
>>> go, the more work we'll have. The question is: what's the benefit of
>>> finer bundles and to which level we want to go. That would help
>>> hiding internal APIs too (for example most of the packages in
>>> blueprint-core should not be exposed ideally).
>>>
>>>>> Another way, if we don't want to keep a clean organization in several
>>>>> maven projects, would be to have each maven project generate a jar,
>>>>> and only put the metadata on the bundle for the whole component.
>>>>
>>>> Again, not sure that I understand, could you give an example?
>>>
>>> The fact we'd keep osgi metadata only for uber-bundles does not
>>> necessarily mean that we'd have to drop our svn layout and the way
>>> maven modules are created.
>>> For example, we would have to combine all blueprint maven projects in
>>> a single one, but only to not create osgi metadata but for the
>>> blueprint-bundle.
>>>
>>> It's really just a thought, I'm sure there would be drawbacks in doing that too.
>>>
>>>> Thanks for the feedback.
>>>>
>>>> Zoe
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 9, 2011 at 19:55, Guillaume Nodet<gn...@gmail.com> wrote:
>>>>>>
>>>>>> Fair point. I missed that quote, which doesn't seem to imply that
>>>>>> require bundle is far from a best practice ...
>>>>>>
>>>>>> On Wed, Feb 9, 2011 at 19:45, zoe slattery<zo...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi
>>>>>>>>
>>>>>>>> Throughout the web page, you refer to "semantic versioning of
>>>>>>>> bundles", but afaik, there's no such thing.
>>>>>>>
>>>>>>> This is a quote from the OSGi semantic versioning white paper:
>>>>>>>
>>>>>>> "Requiring another bundle is similar to a short form of importing all
>>>>>>> the
>>>>>>> exported packages of that required bundle. The version of a bundle must
>>>>>>> therefore semantically aggregate the semantics of all its constituent
>>>>>>> packages. If any of these packages is incompatible with its providers
>>>>>>> then
>>>>>>> the bundle version must increment the minor version. If any of these
>>>>>>> packages is incompatible with consumers, the bundle version must
>>>>>>> increment
>>>>>>> the major version. It is clear, that on average, the version of a bundle
>>>>>>> will be much more volatile than the versions of its constituent
>>>>>>> packages,
>>>>>>> increasing the dependency problems."
>>>>>>>
>>>>>>> This indicated to me that bundles are semantically versioned.
>>>>>>>
>>>>>>> Zoe
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: [DISCUSS] Release process
Posted by Guillaume Nodet <gn...@gmail.com>.
That makes me think that we don't necessarily have to tie the maven
version to the Bundle-Version, which would remove the problem Zoe
mentioned with the release plugin.
So we could release per component (i.e. a bunch of bundles together),
where all bundles would have a maven version of 0.4.0, but the
Bundle-Version would evolve separately.
The bundle semantic versioning service is actually open source, so we
could integrate it into maven-bundle-plugin (or anywhere else). The
problem is that there are cases where a purely semantic change (i.e.
you change a service implementation in an incompatible way without
changing the API) can't be find by such a tool, as it can only work at
the API (class / method) level I think.
On Fri, Feb 11, 2011 at 11:55, Graham Charters <gc...@gmail.com> wrote:
> Zoe,
>
> Thanks for doing this great piece of work, and presenting the options so well.
>
> Personally, I feel, as an enterprise OSGi programming model project,
> we need to be practicing what OSGi preaches. If there are problems
> associated with that, then it would be good if we could feed that back
> into OSGi, or try to fix/improve the processes. We're not the only
> ones to be going down this path.
>
> There are well-documented reasons why separating API from
> implementation is generally a good thing. If we can preserve that, I
> think it would be great. Granted, this results in more modules, which
> will complicate the release process and perhaps make management
> harder. Zoe mentioned 'profiles'. Maybe there are roll-up
> distributions we could build targeted at different types of consumer
> (e.g. full aries, blueprint, application, etc). I'd like to think we
> could also address the uber-bundle use case with distributions and
> subsystem (a little raw at the moment), as we've discussed in the
> past.
>
> I think the semantic versioning tool that Zoe was referring to is
> described in this presentation:
> http://www.osgi.org/wiki/uploads/CommunityEvent2010/OSGi%20Community%202010%20-%20Brada.pdf
> . It's described as "prototype", but that was a little while ago and
> it might be worth a try.
>
> Just my 2 pence.
>
> Regards, Graham.
>
> On 10 February 2011 07:20, Guillaume Nodet <gn...@gmail.com> wrote:
>> On Wed, Feb 9, 2011 at 21:06, zoe slattery <zo...@gmail.com> wrote:
>>> On 09/02/2011 19:26, Guillaume Nodet wrote:
>>>>
>>>> In "Disadvantages of the release by module process" :
>>>>
>>>> #1 what do you imply here ? We can't release the same bundle with the
>>>> exact same version I think. This would mean we'd have to at least
>>>> change the micro version or the qualifier (but preferably the micro
>>>> version), even if the content hasn't changed.
>>>
>>> That's a good question. I can't actually find any ruling that says that we
>>> can't release the same thing twice, so it would come down to a view about
>>> whether it was better to release the same thing twice with the same name, or
>>> the same thing twice with a different name.
>>
>> Maven central will refuse to deploy if one tries to upload another
>> copy of the same artifact / version afaik.
>> Also a release, once voted should be immutable imho.
>>
>>>>
>>>> #3 I guess you made some tests in your branch. so mavne can't cope
>>>> with blueprint-core 1.0.1-SNAPSHOT and blueprint-cm 1.0.3-SNAPSHOT in
>>>> the same build. Or rather, maven can, but the release plugin can't,
>>>> right ? If so and if that can't be easily change, it kinda forbid
>>>> this option imho.
>>>
>>> Yes - that's what I was doing in the branch. And personally I agree with
>>> your conclusion.
>>>>
>>>> #4 i think this is a consequence of applying the semantic versioning
>>>> at the bundle level and I don't see any nice way to solve that
>>>
>>> Indeed.
>>>>
>>>> In the "Disadvantages of releasing by bundle"
>>>> #2 svn: Sling uses a single tree, which makes branching very difficult
>>>> #3: i think if we apply at the package level the rule we talked about,
>>>> i.e. each change which is not a pure bug fix lead to a minor version
>>>> bump (from 1.3.2 to 1.4.0 for example), this would reflect at the
>>>> bundle level, so it should be possible to maintain correct branches
>>>> per bundle
>>>
>>> That would help, but there is a lot of personal judgement in making that
>>> decision. I wonder if we should look at the versioning
>>> tooling in Ace (I think Felix (?) posted a link to it earlier). I read a bit
>>> about it but have not actually tried it.
>>
>> Yes, we can't have any hard rule on that, though we could see it in a
>> different way. Any change that does not ugrade the minor version
>> should be backported to all previous branches. I think it's closer to
>> the usual development model, but lead to the same conclusion.
>>
>> Not sure what you're referring to for the tooling. Any pointer ?
>>
>>>>
>>>> I'd add:
>>>> #4 there is no way to ensure a coherent (meaning to artifact is
>>>> needed twice) set of bundles is sufficient (granted OSGi can easily
>>>> cope with that, but it's kind ugly, and from a maven perspective, very
>>>> difficult to deal with as maven does not allow having two dependencies
>>>> with different versions in the same build)
>>>
>>> I'm not totally sure that I understand you here. Do you mean 'a set of
>>> bundles that we know all work together', like for example the blueprint
>>> bundles?
>>> If so, I had thought about maybe having something like a 'profile' -
>>> basically a pom which would assemble a set of bundles and their source (?)
>>> so a user would just download the pom.xml and run it to assemble something
>>> like what we release in the Blueprint (for example) module.
>>
>> Let's say we have blueprint-core depends on utils [1,2) and
>> transaction-blueprint depends on utils [2,3) at some point in time.
>> There's no way to have maven capture such dependencies if you build
>> something that depends on both blueprint-core and
>> transaction-blueprint.
>> It's also much less convenient for users when you need to know what to install.
>>
>>>>
>>>> If the release by bundle would be favored, I wonder if we should
>>>> follow more closely the felix model, where usually a bundle has very
>>>> few dependencies, i.e. it embeds the API (export + import pacakge) and
>>>> the implementation. This would have the following advantages:
>>>> # we'd roughly combine "release per component" and "release per bundle"
>>>> # all disadvantages listed in "release per bundle" would go away
>>>> # we'd still have all the advantages of "release per bundle" and
>>>> "release per module"
>>>> The release process would be much simplier, consumption much simplier too.
>>>
>>> It's a thought. Do you really mean that we would abandon everything except
>>> the uber-bundles? Or have I misunderstood?
>>
>> That's a suggestion yes. It's a granularity problem. The finer we
>> go, the more work we'll have. The question is: what's the benefit of
>> finer bundles and to which level we want to go. That would help
>> hiding internal APIs too (for example most of the packages in
>> blueprint-core should not be exposed ideally).
>>
>>>> Another way, if we don't want to keep a clean organization in several
>>>> maven projects, would be to have each maven project generate a jar,
>>>> and only put the metadata on the bundle for the whole component.
>>>
>>> Again, not sure that I understand, could you give an example?
>>
>> The fact we'd keep osgi metadata only for uber-bundles does not
>> necessarily mean that we'd have to drop our svn layout and the way
>> maven modules are created.
>> For example, we would have to combine all blueprint maven projects in
>> a single one, but only to not create osgi metadata but for the
>> blueprint-bundle.
>>
>> It's really just a thought, I'm sure there would be drawbacks in doing that too.
>>
>>> Thanks for the feedback.
>>>
>>> Zoe
>>>>
>>>>
>>>>
>>>> On Wed, Feb 9, 2011 at 19:55, Guillaume Nodet<gn...@gmail.com> wrote:
>>>>>
>>>>> Fair point. I missed that quote, which doesn't seem to imply that
>>>>> require bundle is far from a best practice ...
>>>>>
>>>>> On Wed, Feb 9, 2011 at 19:45, zoe slattery<zo...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi
>>>>>>>
>>>>>>> Throughout the web page, you refer to "semantic versioning of
>>>>>>> bundles", but afaik, there's no such thing.
>>>>>>
>>>>>> This is a quote from the OSGi semantic versioning white paper:
>>>>>>
>>>>>> "Requiring another bundle is similar to a short form of importing all
>>>>>> the
>>>>>> exported packages of that required bundle. The version of a bundle must
>>>>>> therefore semantically aggregate the semantics of all its constituent
>>>>>> packages. If any of these packages is incompatible with its providers
>>>>>> then
>>>>>> the bundle version must increment the minor version. If any of these
>>>>>> packages is incompatible with consumers, the bundle version must
>>>>>> increment
>>>>>> the major version. It is clear, that on average, the version of a bundle
>>>>>> will be much more volatile than the versions of its constituent
>>>>>> packages,
>>>>>> increasing the dependency problems."
>>>>>>
>>>>>> This indicated to me that bundles are semantically versioned.
>>>>>>
>>>>>> Zoe
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Release process
Posted by Graham Charters <gc...@gmail.com>.
Zoe,
Thanks for doing this great piece of work, and presenting the options so well.
Personally, I feel, as an enterprise OSGi programming model project,
we need to be practicing what OSGi preaches. If there are problems
associated with that, then it would be good if we could feed that back
into OSGi, or try to fix/improve the processes. We're not the only
ones to be going down this path.
There are well-documented reasons why separating API from
implementation is generally a good thing. If we can preserve that, I
think it would be great. Granted, this results in more modules, which
will complicate the release process and perhaps make management
harder. Zoe mentioned 'profiles'. Maybe there are roll-up
distributions we could build targeted at different types of consumer
(e.g. full aries, blueprint, application, etc). I'd like to think we
could also address the uber-bundle use case with distributions and
subsystem (a little raw at the moment), as we've discussed in the
past.
I think the semantic versioning tool that Zoe was referring to is
described in this presentation:
http://www.osgi.org/wiki/uploads/CommunityEvent2010/OSGi%20Community%202010%20-%20Brada.pdf
. It's described as "prototype", but that was a little while ago and
it might be worth a try.
Just my 2 pence.
Regards, Graham.
On 10 February 2011 07:20, Guillaume Nodet <gn...@gmail.com> wrote:
> On Wed, Feb 9, 2011 at 21:06, zoe slattery <zo...@gmail.com> wrote:
>> On 09/02/2011 19:26, Guillaume Nodet wrote:
>>>
>>> In "Disadvantages of the release by module process" :
>>>
>>> #1 what do you imply here ? We can't release the same bundle with the
>>> exact same version I think. This would mean we'd have to at least
>>> change the micro version or the qualifier (but preferably the micro
>>> version), even if the content hasn't changed.
>>
>> That's a good question. I can't actually find any ruling that says that we
>> can't release the same thing twice, so it would come down to a view about
>> whether it was better to release the same thing twice with the same name, or
>> the same thing twice with a different name.
>
> Maven central will refuse to deploy if one tries to upload another
> copy of the same artifact / version afaik.
> Also a release, once voted should be immutable imho.
>
>>>
>>> #3 I guess you made some tests in your branch. so mavne can't cope
>>> with blueprint-core 1.0.1-SNAPSHOT and blueprint-cm 1.0.3-SNAPSHOT in
>>> the same build. Or rather, maven can, but the release plugin can't,
>>> right ? If so and if that can't be easily change, it kinda forbid
>>> this option imho.
>>
>> Yes - that's what I was doing in the branch. And personally I agree with
>> your conclusion.
>>>
>>> #4 i think this is a consequence of applying the semantic versioning
>>> at the bundle level and I don't see any nice way to solve that
>>
>> Indeed.
>>>
>>> In the "Disadvantages of releasing by bundle"
>>> #2 svn: Sling uses a single tree, which makes branching very difficult
>>> #3: i think if we apply at the package level the rule we talked about,
>>> i.e. each change which is not a pure bug fix lead to a minor version
>>> bump (from 1.3.2 to 1.4.0 for example), this would reflect at the
>>> bundle level, so it should be possible to maintain correct branches
>>> per bundle
>>
>> That would help, but there is a lot of personal judgement in making that
>> decision. I wonder if we should look at the versioning
>> tooling in Ace (I think Felix (?) posted a link to it earlier). I read a bit
>> about it but have not actually tried it.
>
> Yes, we can't have any hard rule on that, though we could see it in a
> different way. Any change that does not ugrade the minor version
> should be backported to all previous branches. I think it's closer to
> the usual development model, but lead to the same conclusion.
>
> Not sure what you're referring to for the tooling. Any pointer ?
>
>>>
>>> I'd add:
>>> #4 there is no way to ensure a coherent (meaning to artifact is
>>> needed twice) set of bundles is sufficient (granted OSGi can easily
>>> cope with that, but it's kind ugly, and from a maven perspective, very
>>> difficult to deal with as maven does not allow having two dependencies
>>> with different versions in the same build)
>>
>> I'm not totally sure that I understand you here. Do you mean 'a set of
>> bundles that we know all work together', like for example the blueprint
>> bundles?
>> If so, I had thought about maybe having something like a 'profile' -
>> basically a pom which would assemble a set of bundles and their source (?)
>> so a user would just download the pom.xml and run it to assemble something
>> like what we release in the Blueprint (for example) module.
>
> Let's say we have blueprint-core depends on utils [1,2) and
> transaction-blueprint depends on utils [2,3) at some point in time.
> There's no way to have maven capture such dependencies if you build
> something that depends on both blueprint-core and
> transaction-blueprint.
> It's also much less convenient for users when you need to know what to install.
>
>>>
>>> If the release by bundle would be favored, I wonder if we should
>>> follow more closely the felix model, where usually a bundle has very
>>> few dependencies, i.e. it embeds the API (export + import pacakge) and
>>> the implementation. This would have the following advantages:
>>> # we'd roughly combine "release per component" and "release per bundle"
>>> # all disadvantages listed in "release per bundle" would go away
>>> # we'd still have all the advantages of "release per bundle" and
>>> "release per module"
>>> The release process would be much simplier, consumption much simplier too.
>>
>> It's a thought. Do you really mean that we would abandon everything except
>> the uber-bundles? Or have I misunderstood?
>
> That's a suggestion yes. It's a granularity problem. The finer we
> go, the more work we'll have. The question is: what's the benefit of
> finer bundles and to which level we want to go. That would help
> hiding internal APIs too (for example most of the packages in
> blueprint-core should not be exposed ideally).
>
>>> Another way, if we don't want to keep a clean organization in several
>>> maven projects, would be to have each maven project generate a jar,
>>> and only put the metadata on the bundle for the whole component.
>>
>> Again, not sure that I understand, could you give an example?
>
> The fact we'd keep osgi metadata only for uber-bundles does not
> necessarily mean that we'd have to drop our svn layout and the way
> maven modules are created.
> For example, we would have to combine all blueprint maven projects in
> a single one, but only to not create osgi metadata but for the
> blueprint-bundle.
>
> It's really just a thought, I'm sure there would be drawbacks in doing that too.
>
>> Thanks for the feedback.
>>
>> Zoe
>>>
>>>
>>>
>>> On Wed, Feb 9, 2011 at 19:55, Guillaume Nodet<gn...@gmail.com> wrote:
>>>>
>>>> Fair point. I missed that quote, which doesn't seem to imply that
>>>> require bundle is far from a best practice ...
>>>>
>>>> On Wed, Feb 9, 2011 at 19:45, zoe slattery<zo...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi
>>>>>>
>>>>>> Throughout the web page, you refer to "semantic versioning of
>>>>>> bundles", but afaik, there's no such thing.
>>>>>
>>>>> This is a quote from the OSGi semantic versioning white paper:
>>>>>
>>>>> "Requiring another bundle is similar to a short form of importing all
>>>>> the
>>>>> exported packages of that required bundle. The version of a bundle must
>>>>> therefore semantically aggregate the semantics of all its constituent
>>>>> packages. If any of these packages is incompatible with its providers
>>>>> then
>>>>> the bundle version must increment the minor version. If any of these
>>>>> packages is incompatible with consumers, the bundle version must
>>>>> increment
>>>>> the major version. It is clear, that on average, the version of a bundle
>>>>> will be much more volatile than the versions of its constituent
>>>>> packages,
>>>>> increasing the dependency problems."
>>>>>
>>>>> This indicated to me that bundles are semantically versioned.
>>>>>
>>>>> Zoe
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>
>>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: [DISCUSS] Release process
Posted by Alasdair Nottingham <no...@apache.org>.
On 10 February 2011 07:20, Guillaume Nodet <gn...@gmail.com> wrote:
> On Wed, Feb 9, 2011 at 21:06, zoe slattery <zo...@gmail.com> wrote:
>> On 09/02/2011 19:26, Guillaume Nodet wrote:
>>>
>>> In "Disadvantages of the release by module process" :
>>>
>>> #1 what do you imply here ? We can't release the same bundle with the
>>> exact same version I think. This would mean we'd have to at least
>>> change the micro version or the qualifier (but preferably the micro
>>> version), even if the content hasn't changed.
>>
>> That's a good question. I can't actually find any ruling that says that we
>> can't release the same thing twice, so it would come down to a view about
>> whether it was better to release the same thing twice with the same name, or
>> the same thing twice with a different name.
>
> Maven central will refuse to deploy if one tries to upload another
> copy of the same artifact / version afaik.
> Also a release, once voted should be immutable imho.
>
+1 a release should be immutable
>>>
>>> #3 I guess you made some tests in your branch. so mavne can't cope
>>> with blueprint-core 1.0.1-SNAPSHOT and blueprint-cm 1.0.3-SNAPSHOT in
>>> the same build. Or rather, maven can, but the release plugin can't,
>>> right ? If so and if that can't be easily change, it kinda forbid
>>> this option imho.
>>
>> Yes - that's what I was doing in the branch. And personally I agree with
>> your conclusion.
>>>
>>> #4 i think this is a consequence of applying the semantic versioning
>>> at the bundle level and I don't see any nice way to solve that
>>
>> Indeed.
>>>
>>> In the "Disadvantages of releasing by bundle"
>>> #2 svn: Sling uses a single tree, which makes branching very difficult
>>> #3: i think if we apply at the package level the rule we talked about,
>>> i.e. each change which is not a pure bug fix lead to a minor version
>>> bump (from 1.3.2 to 1.4.0 for example), this would reflect at the
>>> bundle level, so it should be possible to maintain correct branches
>>> per bundle
>>
>> That would help, but there is a lot of personal judgement in making that
>> decision. I wonder if we should look at the versioning
>> tooling in Ace (I think Felix (?) posted a link to it earlier). I read a bit
>> about it but have not actually tried it.
>
> Yes, we can't have any hard rule on that, though we could see it in a
> different way. Any change that does not ugrade the minor version
> should be backported to all previous branches. I think it's closer to
> the usual development model, but lead to the same conclusion.
>
> Not sure what you're referring to for the tooling. Any pointer ?
>
>>>
>>> I'd add:
>>> #4 there is no way to ensure a coherent (meaning to artifact is
>>> needed twice) set of bundles is sufficient (granted OSGi can easily
>>> cope with that, but it's kind ugly, and from a maven perspective, very
>>> difficult to deal with as maven does not allow having two dependencies
>>> with different versions in the same build)
>>
>> I'm not totally sure that I understand you here. Do you mean 'a set of
>> bundles that we know all work together', like for example the blueprint
>> bundles?
>> If so, I had thought about maybe having something like a 'profile' -
>> basically a pom which would assemble a set of bundles and their source (?)
>> so a user would just download the pom.xml and run it to assemble something
>> like what we release in the Blueprint (for example) module.
>
> Let's say we have blueprint-core depends on utils [1,2) and
> transaction-blueprint depends on utils [2,3) at some point in time.
> There's no way to have maven capture such dependencies if you build
> something that depends on both blueprint-core and
> transaction-blueprint.
> It's also much less convenient for users when you need to know what to install.
>
One of the advantages of OSGi is that exactly this kind of thing is
possible and can be made to work.
If what you are asking for is an easy way to know a set of bundles
that have been tested together and
don't end up pulling in multiple versions of dependencies, like slf4j,
asm, util, then we should find a
solution to that problem, rather than handicap our build/release
process to make this work. If maven
can't cope with this then either we need to improve maven, ditch
maven, or find a non-maven solution.
>>>
>>> If the release by bundle would be favored, I wonder if we should
>>> follow more closely the felix model, where usually a bundle has very
>>> few dependencies, i.e. it embeds the API (export + import pacakge) and
>>> the implementation. This would have the following advantages:
>>> # we'd roughly combine "release per component" and "release per bundle"
>>> # all disadvantages listed in "release per bundle" would go away
>>> # we'd still have all the advantages of "release per bundle" and
>>> "release per module"
>>> The release process would be much simplier, consumption much simplier too.
>>
>> It's a thought. Do you really mean that we would abandon everything except
>> the uber-bundles? Or have I misunderstood?
>
> That's a suggestion yes. It's a granularity problem. The finer we
> go, the more work we'll have. The question is: what's the benefit of
> finer bundles and to which level we want to go. That would help
> hiding internal APIs too (for example most of the packages in
> blueprint-core should not be exposed ideally).
>
-1 API and implementation should remain separate so you can upgrade
your implementation without
needing to re-resolve your clients. If we only have uber bundles we
lose this ability which is a significant
advantage with the services model. If we are going to make a change I
would advocate ditching the uber
bundles, not the api/impl split we have now.
>>> Another way, if we don't want to keep a clean organization in several
>>> maven projects, would be to have each maven project generate a jar,
>>> and only put the metadata on the bundle for the whole component.
>>
>> Again, not sure that I understand, could you give an example?
>
> The fact we'd keep osgi metadata only for uber-bundles does not
> necessarily mean that we'd have to drop our svn layout and the way
> maven modules are created.
> For example, we would have to combine all blueprint maven projects in
> a single one, but only to not create osgi metadata but for the
> blueprint-bundle.
>
> It's really just a thought, I'm sure there would be drawbacks in doing that too.
>
>> Thanks for the feedback.
>>
>> Zoe
>>>
>>>
>>>
>>> On Wed, Feb 9, 2011 at 19:55, Guillaume Nodet<gn...@gmail.com> wrote:
>>>>
>>>> Fair point. I missed that quote, which doesn't seem to imply that
>>>> require bundle is far from a best practice ...
>>>>
>>>> On Wed, Feb 9, 2011 at 19:45, zoe slattery<zo...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi
>>>>>>
>>>>>> Throughout the web page, you refer to "semantic versioning of
>>>>>> bundles", but afaik, there's no such thing.
>>>>>
>>>>> This is a quote from the OSGi semantic versioning white paper:
>>>>>
>>>>> "Requiring another bundle is similar to a short form of importing all
>>>>> the
>>>>> exported packages of that required bundle. The version of a bundle must
>>>>> therefore semantically aggregate the semantics of all its constituent
>>>>> packages. If any of these packages is incompatible with its providers
>>>>> then
>>>>> the bundle version must increment the minor version. If any of these
>>>>> packages is incompatible with consumers, the bundle version must
>>>>> increment
>>>>> the major version. It is clear, that on average, the version of a bundle
>>>>> will be much more volatile than the versions of its constituent
>>>>> packages,
>>>>> increasing the dependency problems."
>>>>>
>>>>> This indicated to me that bundles are semantically versioned.
>>>>>
>>>>> Zoe
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>
>>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: [DISCUSS] Release process
Posted by Guillaume Nodet <gn...@gmail.com>.
On Wed, Feb 9, 2011 at 21:06, zoe slattery <zo...@gmail.com> wrote:
> On 09/02/2011 19:26, Guillaume Nodet wrote:
>>
>> In "Disadvantages of the release by module process" :
>>
>> #1 what do you imply here ? We can't release the same bundle with the
>> exact same version I think. This would mean we'd have to at least
>> change the micro version or the qualifier (but preferably the micro
>> version), even if the content hasn't changed.
>
> That's a good question. I can't actually find any ruling that says that we
> can't release the same thing twice, so it would come down to a view about
> whether it was better to release the same thing twice with the same name, or
> the same thing twice with a different name.
Maven central will refuse to deploy if one tries to upload another
copy of the same artifact / version afaik.
Also a release, once voted should be immutable imho.
>>
>> #3 I guess you made some tests in your branch. so mavne can't cope
>> with blueprint-core 1.0.1-SNAPSHOT and blueprint-cm 1.0.3-SNAPSHOT in
>> the same build. Or rather, maven can, but the release plugin can't,
>> right ? If so and if that can't be easily change, it kinda forbid
>> this option imho.
>
> Yes - that's what I was doing in the branch. And personally I agree with
> your conclusion.
>>
>> #4 i think this is a consequence of applying the semantic versioning
>> at the bundle level and I don't see any nice way to solve that
>
> Indeed.
>>
>> In the "Disadvantages of releasing by bundle"
>> #2 svn: Sling uses a single tree, which makes branching very difficult
>> #3: i think if we apply at the package level the rule we talked about,
>> i.e. each change which is not a pure bug fix lead to a minor version
>> bump (from 1.3.2 to 1.4.0 for example), this would reflect at the
>> bundle level, so it should be possible to maintain correct branches
>> per bundle
>
> That would help, but there is a lot of personal judgement in making that
> decision. I wonder if we should look at the versioning
> tooling in Ace (I think Felix (?) posted a link to it earlier). I read a bit
> about it but have not actually tried it.
Yes, we can't have any hard rule on that, though we could see it in a
different way. Any change that does not ugrade the minor version
should be backported to all previous branches. I think it's closer to
the usual development model, but lead to the same conclusion.
Not sure what you're referring to for the tooling. Any pointer ?
>>
>> I'd add:
>> #4 there is no way to ensure a coherent (meaning to artifact is
>> needed twice) set of bundles is sufficient (granted OSGi can easily
>> cope with that, but it's kind ugly, and from a maven perspective, very
>> difficult to deal with as maven does not allow having two dependencies
>> with different versions in the same build)
>
> I'm not totally sure that I understand you here. Do you mean 'a set of
> bundles that we know all work together', like for example the blueprint
> bundles?
> If so, I had thought about maybe having something like a 'profile' -
> basically a pom which would assemble a set of bundles and their source (?)
> so a user would just download the pom.xml and run it to assemble something
> like what we release in the Blueprint (for example) module.
Let's say we have blueprint-core depends on utils [1,2) and
transaction-blueprint depends on utils [2,3) at some point in time.
There's no way to have maven capture such dependencies if you build
something that depends on both blueprint-core and
transaction-blueprint.
It's also much less convenient for users when you need to know what to install.
>>
>> If the release by bundle would be favored, I wonder if we should
>> follow more closely the felix model, where usually a bundle has very
>> few dependencies, i.e. it embeds the API (export + import pacakge) and
>> the implementation. This would have the following advantages:
>> # we'd roughly combine "release per component" and "release per bundle"
>> # all disadvantages listed in "release per bundle" would go away
>> # we'd still have all the advantages of "release per bundle" and
>> "release per module"
>> The release process would be much simplier, consumption much simplier too.
>
> It's a thought. Do you really mean that we would abandon everything except
> the uber-bundles? Or have I misunderstood?
That's a suggestion yes. It's a granularity problem. The finer we
go, the more work we'll have. The question is: what's the benefit of
finer bundles and to which level we want to go. That would help
hiding internal APIs too (for example most of the packages in
blueprint-core should not be exposed ideally).
>> Another way, if we don't want to keep a clean organization in several
>> maven projects, would be to have each maven project generate a jar,
>> and only put the metadata on the bundle for the whole component.
>
> Again, not sure that I understand, could you give an example?
The fact we'd keep osgi metadata only for uber-bundles does not
necessarily mean that we'd have to drop our svn layout and the way
maven modules are created.
For example, we would have to combine all blueprint maven projects in
a single one, but only to not create osgi metadata but for the
blueprint-bundle.
It's really just a thought, I'm sure there would be drawbacks in doing that too.
> Thanks for the feedback.
>
> Zoe
>>
>>
>>
>> On Wed, Feb 9, 2011 at 19:55, Guillaume Nodet<gn...@gmail.com> wrote:
>>>
>>> Fair point. I missed that quote, which doesn't seem to imply that
>>> require bundle is far from a best practice ...
>>>
>>> On Wed, Feb 9, 2011 at 19:45, zoe slattery<zo...@gmail.com>
>>> wrote:
>>>>
>>>> Hi
>>>>>
>>>>> Throughout the web page, you refer to "semantic versioning of
>>>>> bundles", but afaik, there's no such thing.
>>>>
>>>> This is a quote from the OSGi semantic versioning white paper:
>>>>
>>>> "Requiring another bundle is similar to a short form of importing all
>>>> the
>>>> exported packages of that required bundle. The version of a bundle must
>>>> therefore semantically aggregate the semantics of all its constituent
>>>> packages. If any of these packages is incompatible with its providers
>>>> then
>>>> the bundle version must increment the minor version. If any of these
>>>> packages is incompatible with consumers, the bundle version must
>>>> increment
>>>> the major version. It is clear, that on average, the version of a bundle
>>>> will be much more volatile than the versions of its constituent
>>>> packages,
>>>> increasing the dependency problems."
>>>>
>>>> This indicated to me that bundles are semantically versioned.
>>>>
>>>> Zoe
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Release process
Posted by zoe slattery <zo...@gmail.com>.
On 09/02/2011 19:26, Guillaume Nodet wrote:
> In "Disadvantages of the release by module process" :
>
> #1 what do you imply here ? We can't release the same bundle with the
> exact same version I think. This would mean we'd have to at least
> change the micro version or the qualifier (but preferably the micro
> version), even if the content hasn't changed.
That's a good question. I can't actually find any ruling that says that
we can't release the same thing twice, so it would come down to a view
about whether it was better to release the same thing twice with the
same name, or the same thing twice with a different name.
> #3 I guess you made some tests in your branch. so mavne can't cope
> with blueprint-core 1.0.1-SNAPSHOT and blueprint-cm 1.0.3-SNAPSHOT in
> the same build. Or rather, maven can, but the release plugin can't,
> right ? If so and if that can't be easily change, it kinda forbid
> this option imho.
Yes - that's what I was doing in the branch. And personally I agree with
your conclusion.
> #4 i think this is a consequence of applying the semantic versioning
> at the bundle level and I don't see any nice way to solve that
Indeed.
> In the "Disadvantages of releasing by bundle"
> #2 svn: Sling uses a single tree, which makes branching very difficult
> #3: i think if we apply at the package level the rule we talked about,
> i.e. each change which is not a pure bug fix lead to a minor version
> bump (from 1.3.2 to 1.4.0 for example), this would reflect at the
> bundle level, so it should be possible to maintain correct branches
> per bundle
That would help, but there is a lot of personal judgement in making that
decision. I wonder if we should look at the versioning
tooling in Ace (I think Felix (?) posted a link to it earlier). I read a
bit about it but have not actually tried it.
> I'd add:
> #4 there is no way to ensure a coherent (meaning to artifact is
> needed twice) set of bundles is sufficient (granted OSGi can easily
> cope with that, but it's kind ugly, and from a maven perspective, very
> difficult to deal with as maven does not allow having two dependencies
> with different versions in the same build)
I'm not totally sure that I understand you here. Do you mean 'a set of
bundles that we know all work together', like for example the blueprint
bundles?
If so, I had thought about maybe having something like a 'profile' -
basically a pom which would assemble a set of bundles and their source
(?) so a user would just download the pom.xml and run it to assemble
something like what we release in the Blueprint (for example) module.
>
> If the release by bundle would be favored, I wonder if we should
> follow more closely the felix model, where usually a bundle has very
> few dependencies, i.e. it embeds the API (export + import pacakge) and
> the implementation. This would have the following advantages:
> # we'd roughly combine "release per component" and "release per bundle"
> # all disadvantages listed in "release per bundle" would go away
> # we'd still have all the advantages of "release per bundle" and
> "release per module"
> The release process would be much simplier, consumption much simplier too.
It's a thought. Do you really mean that we would abandon everything
except the uber-bundles? Or have I misunderstood?
> Another way, if we don't want to keep a clean organization in several
> maven projects, would be to have each maven project generate a jar,
> and only put the metadata on the bundle for the whole component.
Again, not sure that I understand, could you give an example?
Thanks for the feedback.
Zoe
>
>
>
> On Wed, Feb 9, 2011 at 19:55, Guillaume Nodet<gn...@gmail.com> wrote:
>> Fair point. I missed that quote, which doesn't seem to imply that
>> require bundle is far from a best practice ...
>>
>> On Wed, Feb 9, 2011 at 19:45, zoe slattery<zo...@gmail.com> wrote:
>>> Hi
>>>> Throughout the web page, you refer to "semantic versioning of
>>>> bundles", but afaik, there's no such thing.
>>> This is a quote from the OSGi semantic versioning white paper:
>>>
>>> "Requiring another bundle is similar to a short form of importing all the
>>> exported packages of that required bundle. The version of a bundle must
>>> therefore semantically aggregate the semantics of all its constituent
>>> packages. If any of these packages is incompatible with its providers then
>>> the bundle version must increment the minor version. If any of these
>>> packages is incompatible with consumers, the bundle version must increment
>>> the major version. It is clear, that on average, the version of a bundle
>>> will be much more volatile than the versions of its constituent packages,
>>> increasing the dependency problems."
>>>
>>> This indicated to me that bundles are semantically versioned.
>>>
>>> Zoe
>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
Re: [DISCUSS] Release process
Posted by Guillaume Nodet <gn...@gmail.com>.
In "Disadvantages of the release by module process" :
#1 what do you imply here ? We can't release the same bundle with the
exact same version I think. This would mean we'd have to at least
change the micro version or the qualifier (but preferably the micro
version), even if the content hasn't changed.
#3 I guess you made some tests in your branch. so mavne can't cope
with blueprint-core 1.0.1-SNAPSHOT and blueprint-cm 1.0.3-SNAPSHOT in
the same build. Or rather, maven can, but the release plugin can't,
right ? If so and if that can't be easily change, it kinda forbid
this option imho.
#4 i think this is a consequence of applying the semantic versioning
at the bundle level and I don't see any nice way to solve that
In the "Disadvantages of releasing by bundle"
#2 svn: Sling uses a single tree, which makes branching very difficult
#3: i think if we apply at the package level the rule we talked about,
i.e. each change which is not a pure bug fix lead to a minor version
bump (from 1.3.2 to 1.4.0 for example), this would reflect at the
bundle level, so it should be possible to maintain correct branches
per bundle
I'd add:
#4 there is no way to ensure a coherent (meaning to artifact is
needed twice) set of bundles is sufficient (granted OSGi can easily
cope with that, but it's kind ugly, and from a maven perspective, very
difficult to deal with as maven does not allow having two dependencies
with different versions in the same build)
If the release by bundle would be favored, I wonder if we should
follow more closely the felix model, where usually a bundle has very
few dependencies, i.e. it embeds the API (export + import pacakge) and
the implementation. This would have the following advantages:
# we'd roughly combine "release per component" and "release per bundle"
# all disadvantages listed in "release per bundle" would go away
# we'd still have all the advantages of "release per bundle" and
"release per module"
The release process would be much simplier, consumption much simplier too.
Another way, if we don't want to keep a clean organization in several
maven projects, would be to have each maven project generate a jar,
and only put the metadata on the bundle for the whole component.
On Wed, Feb 9, 2011 at 19:55, Guillaume Nodet <gn...@gmail.com> wrote:
> Fair point. I missed that quote, which doesn't seem to imply that
> require bundle is far from a best practice ...
>
> On Wed, Feb 9, 2011 at 19:45, zoe slattery <zo...@gmail.com> wrote:
>> Hi
>>>
>>> Throughout the web page, you refer to "semantic versioning of
>>> bundles", but afaik, there's no such thing.
>>
>> This is a quote from the OSGi semantic versioning white paper:
>>
>> "Requiring another bundle is similar to a short form of importing all the
>> exported packages of that required bundle. The version of a bundle must
>> therefore semantically aggregate the semantics of all its constituent
>> packages. If any of these packages is incompatible with its providers then
>> the bundle version must increment the minor version. If any of these
>> packages is incompatible with consumers, the bundle version must increment
>> the major version. It is clear, that on average, the version of a bundle
>> will be much more volatile than the versions of its constituent packages,
>> increasing the dependency problems."
>>
>> This indicated to me that bundles are semantically versioned.
>>
>> Zoe
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Release process
Posted by Guillaume Nodet <gn...@gmail.com>.
Fair point. I missed that quote, which doesn't seem to imply that
require bundle is far from a best practice ...
On Wed, Feb 9, 2011 at 19:45, zoe slattery <zo...@gmail.com> wrote:
> Hi
>>
>> Throughout the web page, you refer to "semantic versioning of
>> bundles", but afaik, there's no such thing.
>
> This is a quote from the OSGi semantic versioning white paper:
>
> "Requiring another bundle is similar to a short form of importing all the
> exported packages of that required bundle. The version of a bundle must
> therefore semantically aggregate the semantics of all its constituent
> packages. If any of these packages is incompatible with its providers then
> the bundle version must increment the minor version. If any of these
> packages is incompatible with consumers, the bundle version must increment
> the major version. It is clear, that on average, the version of a bundle
> will be much more volatile than the versions of its constituent packages,
> increasing the dependency problems."
>
> This indicated to me that bundles are semantically versioned.
>
> Zoe
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Release process
Posted by zoe slattery <zo...@gmail.com>.
Hi
> Throughout the web page, you refer to "semantic versioning of
> bundles", but afaik, there's no such thing.
This is a quote from the OSGi semantic versioning white paper:
"Requiring another bundle is similar to a short form of importing all
the exported packages of that required bundle. The version of a bundle
must therefore semantically aggregate the semantics of all its
constituent packages. If any of these packages is incompatible with its
providers then the bundle version must increment the minor version. If
any of these packages is incompatible with consumers, the bundle version
must increment the major version. It is clear, that on average, the
version of a bundle will be much more volatile than the versions of its
constituent packages, increasing the dependency problems."
This indicated to me that bundles are semantically versioned.
Zoe
Re: [DISCUSS] Release process
Posted by Guillaume Nodet <gn...@gmail.com>.
Thx for the hard work Zoe. I really think for such things, using a
wiki would be better than a web site.
Throughout the web page, you refer to "semantic versioning of
bundles", but afaik, there's no such thing. Semantic versioning
defined is at the package level, as that's where the constraints are
put, not on the bundle version. So if we don't release per bundle
(i.e. we release the whole thing or per component), I don't think we
have to have different versions between a single release. That would
mean we could release a bundle v 1.0 with a package v 2.0 and later
the same bundle in version 1.1 with a package v 3.0 or on the
opposite, a bundle in version 2.0 with a package in version 2.1.
I think if we follow semantic versioning, the package version and
bundle version can / should be completely untied.
On Wed, Feb 9, 2011 at 18:33, zoe slattery <zo...@gmail.com> wrote:
> Hi
>
> I started to pull together both the requirements, information about what we
> do already, extracts from some discussion on the mailing lists and assemble
> them into a web page. The page is here
> http://aries.apache.org/development/ReleaseProcessRequirements.html
>
> I used a web page because I was having difficulty writing it down without
> diagrams, so I thought we needed something with pictures.
>
> I have not attempted to reach any conclusion - I've just tried to list
> advantages and disadvantages as clearly as I can.
>
> I would like to discuss the content of the page on this mailing list,
> principally I would like to understand what advantages and disadvantages I
> have missed in each case. I will update the page based on feedback on this
> list. Eventually, the web page should reflect a consensus on what the
> advantages and disadvantages are in each case.
>
> If anything isn't clear (and I suspect it won't be) please let me know.
>
> Zoe
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com