You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Alasdair Nottingham <no...@apache.org> on 2011/02/04 22:33:44 UTC
[DISCUSSION] Using packageinfo to set package versions
Hi,
Currently we specify versions of exported packages in the pom. This is
not ideal as it means whenever anyone makes a change in a package they
have to edit the pom, also you need to sync the version correctly
between the bundles and the uber bundles.
bnd supports the packageinfo files (and also annotations in
package-info.java), but those are not currently picked up and used in
our build. I raise FELIX-2819 and a workaround has been suggested,
which I managed to get working.
The fix would be to add the following to the default-pom and get the
modules to use the updated parent:
<resource>
<directory>${project.build.sourceDirectory}</directory>
<includes>
<include>**/packageinfo</include>
</includes>
</resource>
Thoughts?
Alasdair
--
Alasdair Nottingham
not@apache.org
Re: [DISCUSSION] Using packageinfo to set package versions
Posted by zoe slattery <zo...@gmail.com>.
On 05/02/2011 08:31, Alasdair Nottingham wrote:
> You have hit onto the problem with semantic versioning. It works just fine for a linear version stream, but not a tree.
Would it be such a big issue to do everything from trunk? I'm not
convinced that it would _if_ we use semantic versioning properly.
> I've been thinking this over for a while, but I can't see a good solution. We could potentially say you don't do a micro increment in trunk, only minor, but this doesn't really work properly.
No :-) - it doesn't.
> Alasdair Nottingham
>
> On 4 Feb 2011, at 23:43, Guillaume Nodet<gn...@gmail.com> wrote:
>
>> On Fri, Feb 4, 2011 at 23:41, Alasdair Nottingham<no...@apache.org> wrote:
>>>
>>> Alasdair Nottingham
>>>
>>> On 4 Feb 2011, at 22:13, Felix Meschberger<fm...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Am Freitag, den 04.02.2011, 21:33 +0000 schrieb Alasdair Nottingham:
>>>>> Hi,
>>>>>
>>>>> Currently we specify versions of exported packages in the pom. This is
>>>>> not ideal as it means whenever anyone makes a change in a package they
>>>>> have to edit the pom,
>>>> You could argue that modifying exported packages is critical, so making
>>>> it harder to do might get people to think twice ... Granted this is kind
>>>> of a weak argument ;-)
>>>>
>>> In fact I want it to be easy, the easier the better. If you change the code the version should increment.
>> So why even bother with having to manually change the version ? I
>> think it should be possible to have the maven-bundle-plugin increment
>> the version depending on the kind of changes by comparing the package
>> signatures and make sure it follows the semantic versioning. Given it
>> has already been done (see
>> https://www.assembla.com/wiki/show/obcc/OSGi_Version_Generator) I
>> think we could add that to the maven bundle plugin.
>>
>>
>> However, there's something which is worrying me about the semantic
>> versioning. I don't think it can cope with maintenance branches. The
>> process of incrementing a package version works well in a single line
>> of releases, but not in a tree, so can't ever release a package which
>> doesn't contain all the previous changes. Or rather the process works
>> for a given package, but the problem is that our bundles do not only
>> contain a single package. Let's take a concrete example.
>> I have a bundle version 3.0 which has two packages foo / 1.0 + bar / 1.0.
>> In a future release 3.1 of that bundle, i add one functionality to the
>> foo package and a minor modification to the bar package, so I release
>> this with foo / 1.1 + bar / 1.0.1.
>> Some time later, I find a bug in the bar package which I'd like to fix
>> for both minor versions of my bundle. If I do so, I'd end up with a
>> bundle 3.0.1 with foo / 1.0 + bar / 1.0.1 and a bundle 3.1.1 with foo
>> / 1.1 + bar / 1.0.2. That's not really possible because the two bar /
>> 1.0.1 package would be different.
>> Possible solutions:
>> * backport into 3.0 branch the change that modification that caused
>> the bump from 1.0 to 1.0.1 (when releasing 3.1). However, this may
>> not be a big fix, maybe a small improvement that I don't want to
>> backport, so I don't think this solution is a good idea
>> * never release a bundle which exports multiple packages: that sucks too
>> * don't do maintenance release: i don't think we want that
>> * consider that any modification you may not want to backport in a
>> maintenance branch later should lead to bump the minor version of a
>> package, even if the signature of the package doesn't really change
>> I think the last one is the only one applicable. Thoughts ?
>>
>>
>>>> On the other hand, the problem is always the same: you have to update
>>>> information in a secondary location -- regardless of whether this is the
>>>> packaginfo or the pom.xml file.
>>>>
>>> Right, and packageinfo is right next to the classes you just updated, closer = better IMHO.
>>>
>>>> The advantage of doing it in the pom.xml file IMHO is that you have a
>>>> complete overview of your exports incl. their versions. YMMV.
>>>>
>>> The downside in our case is you have to update the bundle and the uber bundle, bigger chance of getting out of sync, which would be very very bad.
>>>
>>>>> also you need to sync the version correctly
>>>>> between the bundles
>>>> the bundle plugin takes care of this (fortunately) -- assuming you mean
>>>> the "Import-Package" versioning.
>>>>
>>> I'm trying to address export bundle. I'm happy with the import package stuff.
>>>
>>>>> and the uber bundles.
>>>>> bnd supports the packageinfo files (and also annotations in
>>>>> package-info.java), but those are not currently picked up and used in
>>>>> our build. I raise FELIX-2819 and a workaround has been suggested,
>>>>> which I managed to get working.
>>>>>
>>>>> The fix would be to add the following to the default-pom and get the
>>>>> modules to use the updated parent:
>>>>>
>>>>> <resource>
>>>>> <directory>${project.build.sourceDirectory}</directory>
>>>>> <includes>
>>>>> <include>**/packageinfo</include>
>>>>> </includes>
>>>>> </resource>
>>>> Unfortunately, you will still have the regular resources in the
>>>> src/main/resources tree. So you have to explicitly list this to in the
>>>> <resources> element of the parent POM to not miss these...
>>> Right, this is already in our parent pom, so I'm proposing adding this in addition to the other resources statements already there.
>>>
>>>> In Sling we currently maintain the exported package version in the POMs.
>>>> This works fine but is also kind of suboptimal.
>>>>
>>>> I think the most important thing is to make it consistent: Do it either
>>>> way, but stick to.
>>> I agree. I think we should use packageinfo though :)
>>>
>>>> Regards
>>>> Felix
>>>>
>>>>> Thoughts?
>>>>> Alasdair
>>>>>
>>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
Re: [DISCUSSION] Using packageinfo to set package versions
Posted by Alasdair Nottingham <no...@apache.org>.
You have hit onto the problem with semantic versioning. It works just fine for a linear version stream, but not a tree.
I've been thinking this over for a while, but I can't see a good solution. We could potentially say you don't do a micro increment in trunk, only minor, but this doesn't really work properly.
Alasdair Nottingham
On 4 Feb 2011, at 23:43, Guillaume Nodet <gn...@gmail.com> wrote:
> On Fri, Feb 4, 2011 at 23:41, Alasdair Nottingham <no...@apache.org> wrote:
>>
>>
>> Alasdair Nottingham
>>
>> On 4 Feb 2011, at 22:13, Felix Meschberger <fm...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Am Freitag, den 04.02.2011, 21:33 +0000 schrieb Alasdair Nottingham:
>>>> Hi,
>>>>
>>>> Currently we specify versions of exported packages in the pom. This is
>>>> not ideal as it means whenever anyone makes a change in a package they
>>>> have to edit the pom,
>>>
>>> You could argue that modifying exported packages is critical, so making
>>> it harder to do might get people to think twice ... Granted this is kind
>>> of a weak argument ;-)
>>>
>>
>> In fact I want it to be easy, the easier the better. If you change the code the version should increment.
>
> So why even bother with having to manually change the version ? I
> think it should be possible to have the maven-bundle-plugin increment
> the version depending on the kind of changes by comparing the package
> signatures and make sure it follows the semantic versioning. Given it
> has already been done (see
> https://www.assembla.com/wiki/show/obcc/OSGi_Version_Generator) I
> think we could add that to the maven bundle plugin.
>
>
> However, there's something which is worrying me about the semantic
> versioning. I don't think it can cope with maintenance branches. The
> process of incrementing a package version works well in a single line
> of releases, but not in a tree, so can't ever release a package which
> doesn't contain all the previous changes. Or rather the process works
> for a given package, but the problem is that our bundles do not only
> contain a single package. Let's take a concrete example.
> I have a bundle version 3.0 which has two packages foo / 1.0 + bar / 1.0.
> In a future release 3.1 of that bundle, i add one functionality to the
> foo package and a minor modification to the bar package, so I release
> this with foo / 1.1 + bar / 1.0.1.
> Some time later, I find a bug in the bar package which I'd like to fix
> for both minor versions of my bundle. If I do so, I'd end up with a
> bundle 3.0.1 with foo / 1.0 + bar / 1.0.1 and a bundle 3.1.1 with foo
> / 1.1 + bar / 1.0.2. That's not really possible because the two bar /
> 1.0.1 package would be different.
> Possible solutions:
> * backport into 3.0 branch the change that modification that caused
> the bump from 1.0 to 1.0.1 (when releasing 3.1). However, this may
> not be a big fix, maybe a small improvement that I don't want to
> backport, so I don't think this solution is a good idea
> * never release a bundle which exports multiple packages: that sucks too
> * don't do maintenance release: i don't think we want that
> * consider that any modification you may not want to backport in a
> maintenance branch later should lead to bump the minor version of a
> package, even if the signature of the package doesn't really change
> I think the last one is the only one applicable. Thoughts ?
>
>
>>> On the other hand, the problem is always the same: you have to update
>>> information in a secondary location -- regardless of whether this is the
>>> packaginfo or the pom.xml file.
>>>
>>
>> Right, and packageinfo is right next to the classes you just updated, closer = better IMHO.
>>
>>> The advantage of doing it in the pom.xml file IMHO is that you have a
>>> complete overview of your exports incl. their versions. YMMV.
>>>
>>
>> The downside in our case is you have to update the bundle and the uber bundle, bigger chance of getting out of sync, which would be very very bad.
>>
>>>> also you need to sync the version correctly
>>>> between the bundles
>>>
>>> the bundle plugin takes care of this (fortunately) -- assuming you mean
>>> the "Import-Package" versioning.
>>>
>>
>> I'm trying to address export bundle. I'm happy with the import package stuff.
>>
>>>> and the uber bundles.
>>>
>>>>
>>>> bnd supports the packageinfo files (and also annotations in
>>>> package-info.java), but those are not currently picked up and used in
>>>> our build. I raise FELIX-2819 and a workaround has been suggested,
>>>> which I managed to get working.
>>>>
>>>> The fix would be to add the following to the default-pom and get the
>>>> modules to use the updated parent:
>>>>
>>>> <resource>
>>>> <directory>${project.build.sourceDirectory}</directory>
>>>> <includes>
>>>> <include>**/packageinfo</include>
>>>> </includes>
>>>> </resource>
>>>
>>> Unfortunately, you will still have the regular resources in the
>>> src/main/resources tree. So you have to explicitly list this to in the
>>> <resources> element of the parent POM to not miss these...
>>
>> Right, this is already in our parent pom, so I'm proposing adding this in addition to the other resources statements already there.
>>
>>>
>>> In Sling we currently maintain the exported package version in the POMs.
>>> This works fine but is also kind of suboptimal.
>>>
>>> I think the most important thing is to make it consistent: Do it either
>>> way, but stick to.
>>
>> I agree. I think we should use packageinfo though :)
>>
>>>
>>> Regards
>>> Felix
>>>
>>>>
>>>> Thoughts?
>>>> Alasdair
>>>>
>>>
>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: [DISCUSSION] Using packageinfo to set package versions
Posted by Mark Nuttall <mn...@apache.org>.
Guillaume wrote,
> However, there's something which is worrying me about the semantic
> versioning. I don't think it can cope with maintenance branches.
I ran into this same problem a few days ago, when I made a micro
increment to a bundle version in our internal development stream. It
turns out that our service team's approach, is simply to not change
package or bundle versions in their service streams. Perhaps they'll
put a 'patch level' in the qualifier field. It's not ideal but it
reflects Guillaume's point: OSGi versioning is not designed to handle
muliple code branches.
We could do something similar if we agree to keep change in
maintenance branches down to an absolute minimum.
Regards,
Mark
On 4 February 2011 23:43, Guillaume Nodet <gn...@gmail.com> wrote:
> On Fri, Feb 4, 2011 at 23:41, Alasdair Nottingham <no...@apache.org> wrote:
>>
>>
>> Alasdair Nottingham
>>
>> On 4 Feb 2011, at 22:13, Felix Meschberger <fm...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Am Freitag, den 04.02.2011, 21:33 +0000 schrieb Alasdair Nottingham:
>>>> Hi,
>>>>
>>>> Currently we specify versions of exported packages in the pom. This is
>>>> not ideal as it means whenever anyone makes a change in a package they
>>>> have to edit the pom,
>>>
>>> You could argue that modifying exported packages is critical, so making
>>> it harder to do might get people to think twice ... Granted this is kind
>>> of a weak argument ;-)
>>>
>>
>> In fact I want it to be easy, the easier the better. If you change the code the version should increment.
>
> So why even bother with having to manually change the version ? I
> think it should be possible to have the maven-bundle-plugin increment
> the version depending on the kind of changes by comparing the package
> signatures and make sure it follows the semantic versioning. Given it
> has already been done (see
> https://www.assembla.com/wiki/show/obcc/OSGi_Version_Generator) I
> think we could add that to the maven bundle plugin.
>
>
> However, there's something which is worrying me about the semantic
> versioning. I don't think it can cope with maintenance branches. The
> process of incrementing a package version works well in a single line
> of releases, but not in a tree, so can't ever release a package which
> doesn't contain all the previous changes. Or rather the process works
> for a given package, but the problem is that our bundles do not only
> contain a single package. Let's take a concrete example.
> I have a bundle version 3.0 which has two packages foo / 1.0 + bar / 1.0.
> In a future release 3.1 of that bundle, i add one functionality to the
> foo package and a minor modification to the bar package, so I release
> this with foo / 1.1 + bar / 1.0.1.
> Some time later, I find a bug in the bar package which I'd like to fix
> for both minor versions of my bundle. If I do so, I'd end up with a
> bundle 3.0.1 with foo / 1.0 + bar / 1.0.1 and a bundle 3.1.1 with foo
> / 1.1 + bar / 1.0.2. That's not really possible because the two bar /
> 1.0.1 package would be different.
> Possible solutions:
> * backport into 3.0 branch the change that modification that caused
> the bump from 1.0 to 1.0.1 (when releasing 3.1). However, this may
> not be a big fix, maybe a small improvement that I don't want to
> backport, so I don't think this solution is a good idea
> * never release a bundle which exports multiple packages: that sucks too
> * don't do maintenance release: i don't think we want that
> * consider that any modification you may not want to backport in a
> maintenance branch later should lead to bump the minor version of a
> package, even if the signature of the package doesn't really change
> I think the last one is the only one applicable. Thoughts ?
>
>
>>> On the other hand, the problem is always the same: you have to update
>>> information in a secondary location -- regardless of whether this is the
>>> packaginfo or the pom.xml file.
>>>
>>
>> Right, and packageinfo is right next to the classes you just updated, closer = better IMHO.
>>
>>> The advantage of doing it in the pom.xml file IMHO is that you have a
>>> complete overview of your exports incl. their versions. YMMV.
>>>
>>
>> The downside in our case is you have to update the bundle and the uber bundle, bigger chance of getting out of sync, which would be very very bad.
>>
>>>> also you need to sync the version correctly
>>>> between the bundles
>>>
>>> the bundle plugin takes care of this (fortunately) -- assuming you mean
>>> the "Import-Package" versioning.
>>>
>>
>> I'm trying to address export bundle. I'm happy with the import package stuff.
>>
>>>> and the uber bundles.
>>>
>>>>
>>>> bnd supports the packageinfo files (and also annotations in
>>>> package-info.java), but those are not currently picked up and used in
>>>> our build. I raise FELIX-2819 and a workaround has been suggested,
>>>> which I managed to get working.
>>>>
>>>> The fix would be to add the following to the default-pom and get the
>>>> modules to use the updated parent:
>>>>
>>>> <resource>
>>>> <directory>${project.build.sourceDirectory}</directory>
>>>> <includes>
>>>> <include>**/packageinfo</include>
>>>> </includes>
>>>> </resource>
>>>
>>> Unfortunately, you will still have the regular resources in the
>>> src/main/resources tree. So you have to explicitly list this to in the
>>> <resources> element of the parent POM to not miss these...
>>
>> Right, this is already in our parent pom, so I'm proposing adding this in addition to the other resources statements already there.
>>
>>>
>>> In Sling we currently maintain the exported package version in the POMs.
>>> This works fine but is also kind of suboptimal.
>>>
>>> I think the most important thing is to make it consistent: Do it either
>>> way, but stick to.
>>
>> I agree. I think we should use packageinfo though :)
>>
>>>
>>> Regards
>>> Felix
>>>
>>>>
>>>> Thoughts?
>>>> Alasdair
>>>>
>>>
>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: [DISCUSSION] Using packageinfo to set package versions
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Dienstag, den 08.02.2011, 16:48 +0000 schrieb zoe slattery:
> Hi Felix
> > I think one of the ties that you have is that your module poms are both
> > parent poms and reactor poms. In my experience in a modular development
> > environment this poses a lot of problems, which is why we (Sling but
> > also our company internal projects) clearly separate between parent POM
> > and reactor POM.
> Yes - thanks for this, they are both the same and I will see what I can
> do by pulling them apart.
> > In your quiesce case, this would given the following structure:
> >
> > quiesce
> > +--> pom.xml (reactor only)
> > +--> parent
> > +--> pom.xml<-+
> > +--> api |
> > +--> pom.xml --+
> > +--> manager |
> > +--> pom.xml --+
> > +--> manager-itest |
> > +--> pom.xml --+
> >
> > And in the parent POM we only use dependency management for a small
> > select number of dependencies and have full dependencies in each pom.
> Having looked at Sling, what you have doesn't seem to be quite like
> this. No parent directory? Or am I misunderstanding something?
We have only one single parent pom in trunk/parent. Other than that we
have a few reactor poms.
In the parent pom we just a handful managed depdencies (servlet API, JCR
API, SLF4J API, JUnit). Other than that each bundle has its own unique
dependencies.
Regards
Felix
> > Its maybe harder to setup but pays off later -- and we don't update
> > dependencies on each release.
> >
> >
> > Regards
> > Felix
> >
> >> This is rather ugly, but it does work - see this pom.xml for quiecse
> >> https://svn.apache.org/repos/asf/aries/branches/experimental-release-by-module/quiesce/pom.xml.
> >> This means that we'd never increase a bundle version artificially and
> >> when we came to release (say) quiesce we would not re-release the same
> >> code with a different name. The release process still gives you all the
> >> source for the whole quiesce module - which I suppose is OK.
> >>
> >>>
> >
> >
>
Re: [DISCUSSION] Using packageinfo to set package versions
Posted by zoe slattery <zo...@gmail.com>.
Hi Felix
> I think one of the ties that you have is that your module poms are both
> parent poms and reactor poms. In my experience in a modular development
> environment this poses a lot of problems, which is why we (Sling but
> also our company internal projects) clearly separate between parent POM
> and reactor POM.
Yes - thanks for this, they are both the same and I will see what I can
do by pulling them apart.
> In your quiesce case, this would given the following structure:
>
> quiesce
> +--> pom.xml (reactor only)
> +--> parent
> +--> pom.xml<-+
> +--> api |
> +--> pom.xml --+
> +--> manager |
> +--> pom.xml --+
> +--> manager-itest |
> +--> pom.xml --+
>
> And in the parent POM we only use dependency management for a small
> select number of dependencies and have full dependencies in each pom.
Having looked at Sling, what you have doesn't seem to be quite like
this. No parent directory? Or am I misunderstanding something?
> Its maybe harder to setup but pays off later -- and we don't update
> dependencies on each release.
>
>
> Regards
> Felix
>
>> This is rather ugly, but it does work - see this pom.xml for quiecse
>> https://svn.apache.org/repos/asf/aries/branches/experimental-release-by-module/quiesce/pom.xml.
>> This means that we'd never increase a bundle version artificially and
>> when we came to release (say) quiesce we would not re-release the same
>> code with a different name. The release process still gives you all the
>> source for the whole quiesce module - which I suppose is OK.
>>
>>>
>
>
Re: [DISCUSSION] Using packageinfo to set package versions
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Sonntag, den 06.02.2011, 16:42 +0000 schrieb zoe slattery:
> Hi
> > Yes, each bundle has its own change log because each bundle release has
> > its own Version identifier in JIRA. But we collect similar bundles into
> > bigger compoinents. For example all scripting related bundles (api,
> > core, scripting language support) are under the same "Scripting"
> > component.
>
>
> Sling is an interesting model. The essential difference between what you
> do and what we currently do in Aries is that our bundles are grouped in
> modules and that the module is the thing that we release. If we stay
> with this we either need to accept that we may well release exactly the
> same thing twice (or more) under different names or find a way to
> release the bundles that have changed when we release the module. To do
> this, after a release (say 0.3), the module version changes to
> 0.4-SNAPSHOT but it's internal dependencies (sub modules) should all be
> on released artifacts. The sub-modules would need to be commented out of
> the module's pom. When a change is required in the sub-module it's
> version has to change to A.B.C-SNAPSHOT and the it has to be listed as a
> module in the parent modules pom again.
I think one of the ties that you have is that your module poms are both
parent poms and reactor poms. In my experience in a modular development
environment this poses a lot of problems, which is why we (Sling but
also our company internal projects) clearly separate between parent POM
and reactor POM.
In your quiesce case, this would given the following structure:
quiesce
+--> pom.xml (reactor only)
+--> parent
+--> pom.xml <-+
+--> api |
+--> pom.xml --+
+--> manager |
+--> pom.xml --+
+--> manager-itest |
+--> pom.xml --+
And in the parent POM we only use dependency management for a small
select number of dependencies and have full dependencies in each pom.
Its maybe harder to setup but pays off later -- and we don't update
dependencies on each release.
Regards
Felix
>
> This is rather ugly, but it does work - see this pom.xml for quiecse
> https://svn.apache.org/repos/asf/aries/branches/experimental-release-by-module/quiesce/pom.xml.
> This means that we'd never increase a bundle version artificially and
> when we came to release (say) quiesce we would not re-release the same
> code with a different name. The release process still gives you all the
> source for the whole quiesce module - which I suppose is OK.
>
> >
> >
>
Re: [DISCUSSION] Using packageinfo to set package versions
Posted by zoe slattery <zo...@gmail.com>.
Hi
> Yes, each bundle has its own change log because each bundle release has
> its own Version identifier in JIRA. But we collect similar bundles into
> bigger compoinents. For example all scripting related bundles (api,
> core, scripting language support) are under the same "Scripting"
> component.
Sling is an interesting model. The essential difference between what you
do and what we currently do in Aries is that our bundles are grouped in
modules and that the module is the thing that we release. If we stay
with this we either need to accept that we may well release exactly the
same thing twice (or more) under different names or find a way to
release the bundles that have changed when we release the module. To do
this, after a release (say 0.3), the module version changes to
0.4-SNAPSHOT but it's internal dependencies (sub modules) should all be
on released artifacts. The sub-modules would need to be commented out of
the module's pom. When a change is required in the sub-module it's
version has to change to A.B.C-SNAPSHOT and the it has to be listed as a
module in the parent modules pom again.
This is rather ugly, but it does work - see this pom.xml for quiecse
https://svn.apache.org/repos/asf/aries/branches/experimental-release-by-module/quiesce/pom.xml.
This means that we'd never increase a bundle version artificially and
when we came to release (say) quiesce we would not re-release the same
code with a different name. The release process still gives you all the
source for the whole quiesce module - which I suppose is OK.
>
>
Re: [DISCUSSION] Using packageinfo to set package versions
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Samstag, den 05.02.2011, 14:28 +0000 schrieb zoe slattery:
> On 05/02/2011 12:38, Guillaume Nodet wrote:
> > I think we may want to stick too much to semantic versioning.
> Is there a 'not' missing?
> > Don't
> > get me wrong, I agree with the compatibility rules semantic and we
> > should support them: i.e. if there is an incompatible change, the
> > major version has to be different and if there is a compatible change,
> > the minor version has to be different.
> > However, I think it does not imply we need to be strict about *when*
> > we change the version of the package. If we align the package version
> > changes with the bundle version changes (that does not necessarily
> > imply they have to be the same), i.e. when we change from aries 0.3 to
> > aries 0.4, the packages are bumped too from a minor version, this
> > leaves some place to do branch fixes using minor versions on the
> > package.
That's what I tried to say earlier: increasing the version number
without changing anything is confusing. Thus I would not do it.
> >
> > I think we face two different development model basically:
> >
> > * use a more traditional development model using a tree of versions
> > (either at the component level or for the whole tree). We can support
> > branch fixes and micro releases in a tree. We need to somewhat align
> > the package version changes to the bundle version change. This means
> > we may end up with multiple identical packages with the same version
> > number (though I suppose real api and library packages are somewhat
> > different, as pure API packages that do not contain any code could
> > have their own versioning not tied to this). We can release / branch
> > per component or from the root (still to be decided, but completely
> > orthogonal to the problem)
> I think we need to be able to articulate some clear 'rules' on versions.
> > * use the model that felix / sling follows and have a versioning
> > scheme per bundle with no way to maintain bug fix branches. Each
> > bundle has to be released independantly with its own release notes and
> > all. I think we'd have to flatten our svn tree as there's no real
> > need to have a tree of modules (we can use maven profiles if we want
> > to build only a given component). The consequence is that we also
> > need to maintain documentation about compatiblity, as users see the
> > bundle versions, not really the package versions and we need to have a
> > way to tell them which bundles are supposed to work together (i think
> > we have more than 100 bundles in the whole tree I think, so not sure
> > what kind of documentation could give an overview of that ;-) ).
> So, just to consider blueprint, which currently has 12 bundles, we would
> - release each bundle separately, with its own vote. Its own JIRA
> component, its own release notes, its own release announce etc.
No, no, no, yes, no.
In Sling we sometimes release multiple bundles at once. Such votes will
also be announced together.
Yes, each bundle has its own change log because each bundle release has
its own Version identifier in JIRA. But we collect similar bundles into
bigger compoinents. For example all scripting related bundles (api,
core, scripting language support) are under the same "Scripting"
component.
> - say we have blueprint-something at version x.y.z-SNAPSHOT, and we
> want to release version x.y.z. In trunk there is also
> blueprint-anotherthing at version a.b.c-SNAPSHOT. If we release
> blueprint-something x.y.z, what do we say about what it has been
> built/tested with? Or maybe we have to release blueprint-anotherthing
> a.b.c at the same time?
I would say, that there is no hard rule.
Regards
Felix
>
>
> > It seems any in-between solution has some big problems. Currently,
> > we're more on the first solution and I think it's way easier for us
> > and for our users.
> It's easier for us. But what we do at the moment is definitely wrong wrt
> to package versions. Is the implication of what you say above that you
> believe we should not use semantic versioning (strictly) for packages?
> Or do you think we can achieve this with some modifications to the
> current process? That's what I was trying to explore. Independent bundle
> releases does not seem practical (for us) unless we opted to combine
> everything in a single uber bundle (and I think there were arguments
> against that).
>
> Zoe
> > On Sat, Feb 5, 2011 at 11:03, Felix Meschberger<fm...@gmail.com> wrote:
> >> Hi,
> >>
> >> Am Samstag, den 05.02.2011, 00:43 +0100 schrieb Guillaume Nodet:
> >>>> In fact I want it to be easy, the easier the better. If you change the code the version should increment.
> >>> So why even bother with having to manually change the version ? I
> >>> think it should be possible to have the maven-bundle-plugin increment
> >>> the version depending on the kind of changes by comparing the package
> >>> signatures and make sure it follows the semantic versioning. Given it
> >>> has already been done (see
> >>> https://www.assembla.com/wiki/show/obcc/OSGi_Version_Generator) I
> >>> think we could add that to the maven bundle plugin.
> >> +1 !
> >>
> >> (Not sure, whether the Bundle Plugin does not get overloaded, though)
> >>
> >>>
> >>> However, there's something which is worrying me about the semantic
> >>> versioning. I don't think it can cope with maintenance branches. The
> >>> process of incrementing a package version works well in a single line
> >>> of releases, but not in a tree, so can't ever release a package which
> >>> doesn't contain all the previous changes. Or rather the process works
> >>> for a given package, but the problem is that our bundles do not only
> >>> contain a single package. Let's take a concrete example.
> >>> I have a bundle version 3.0 which has two packages foo / 1.0 + bar / 1.0.
> >>> In a future release 3.1 of that bundle, i add one functionality to the
> >>> foo package and a minor modification to the bar package, so I release
> >>> this with foo / 1.1 + bar / 1.0.1.
> >>> Some time later, I find a bug in the bar package which I'd like to fix
> >>> for both minor versions of my bundle. If I do so, I'd end up with a
> >>> bundle 3.0.1 with foo / 1.0 + bar / 1.0.1 and a bundle 3.1.1 with foo
> >>> / 1.1 + bar / 1.0.2. That's not really possible because the two bar /
> >>> 1.0.1 package would be different.
> >>> Possible solutions:
> >>> * backport into 3.0 branch the change that modification that caused
> >>> the bump from 1.0 to 1.0.1 (when releasing 3.1). However, this may
> >>> not be a big fix, maybe a small improvement that I don't want to
> >>> backport, so I don't think this solution is a good idea
> >>> * never release a bundle which exports multiple packages: that sucks too
> >>> * don't do maintenance release: i don't think we want that
> >>> * consider that any modification you may not want to backport in a
> >>> maintenance branch later should lead to bump the minor version of a
> >>> package, even if the signature of the package doesn't really change
> >>> I think the last one is the only one applicable. Thoughts ?
> >> Well branches pose just more than this single problem, which is why I
> >> generally try to avoid release branches like the plague ...
> >>
> >> In this concrete example, you might probably have to either backport
> >> everything from the bar/1.0.1 package or employ qualifier increments.
> >>
> >> At the end of the day, this should not prevent the project from adopting
> >> semantic versioning, because the benefits tremendously outweigh these
> >> minor costs.
> >>
> >> Regards
> >> Felix
> >>
> >>>
> >>>>> On the other hand, the problem is always the same: you have to update
> >>>>> information in a secondary location -- regardless of whether this is the
> >>>>> packaginfo or the pom.xml file.
> >>>>>
> >>>> Right, and packageinfo is right next to the classes you just updated, closer = better IMHO.
> >>>>
> >>>>> The advantage of doing it in the pom.xml file IMHO is that you have a
> >>>>> complete overview of your exports incl. their versions. YMMV.
> >>>>>
> >>>> The downside in our case is you have to update the bundle and the uber bundle, bigger chance of getting out of sync, which would be very very bad.
> >>>>
> >>>>>> also you need to sync the version correctly
> >>>>>> between the bundles
> >>>>> the bundle plugin takes care of this (fortunately) -- assuming you mean
> >>>>> the "Import-Package" versioning.
> >>>>>
> >>>> I'm trying to address export bundle. I'm happy with the import package stuff.
> >>>>
> >>>>>> and the uber bundles.
> >>>>>> bnd supports the packageinfo files (and also annotations in
> >>>>>> package-info.java), but those are not currently picked up and used in
> >>>>>> our build. I raise FELIX-2819 and a workaround has been suggested,
> >>>>>> which I managed to get working.
> >>>>>>
> >>>>>> The fix would be to add the following to the default-pom and get the
> >>>>>> modules to use the updated parent:
> >>>>>>
> >>>>>> <resource>
> >>>>>> <directory>${project.build.sourceDirectory}</directory>
> >>>>>> <includes>
> >>>>>> <include>**/packageinfo</include>
> >>>>>> </includes>
> >>>>>> </resource>
> >>>>> Unfortunately, you will still have the regular resources in the
> >>>>> src/main/resources tree. So you have to explicitly list this to in the
> >>>>> <resources> element of the parent POM to not miss these...
> >>>> Right, this is already in our parent pom, so I'm proposing adding this in addition to the other resources statements already there.
> >>>>
> >>>>> In Sling we currently maintain the exported package version in the POMs.
> >>>>> This works fine but is also kind of suboptimal.
> >>>>>
> >>>>> I think the most important thing is to make it consistent: Do it either
> >>>>> way, but stick to.
> >>>> I agree. I think we should use packageinfo though :)
> >>>>
> >>>>> Regards
> >>>>> Felix
> >>>>>
> >>>>>> Thoughts?
> >>>>>> Alasdair
> >>>>>>
> >>>>>
> >>>
> >>>
> >>
> >>
> >
> >
>
Re: [DISCUSSION] Using packageinfo to set package versions
Posted by zoe slattery <zo...@gmail.com>.
On 05/02/2011 12:38, Guillaume Nodet wrote:
> I think we may want to stick too much to semantic versioning.
Is there a 'not' missing?
> Don't
> get me wrong, I agree with the compatibility rules semantic and we
> should support them: i.e. if there is an incompatible change, the
> major version has to be different and if there is a compatible change,
> the minor version has to be different.
> However, I think it does not imply we need to be strict about *when*
> we change the version of the package. If we align the package version
> changes with the bundle version changes (that does not necessarily
> imply they have to be the same), i.e. when we change from aries 0.3 to
> aries 0.4, the packages are bumped too from a minor version, this
> leaves some place to do branch fixes using minor versions on the
> package.
>
> I think we face two different development model basically:
>
> * use a more traditional development model using a tree of versions
> (either at the component level or for the whole tree). We can support
> branch fixes and micro releases in a tree. We need to somewhat align
> the package version changes to the bundle version change. This means
> we may end up with multiple identical packages with the same version
> number (though I suppose real api and library packages are somewhat
> different, as pure API packages that do not contain any code could
> have their own versioning not tied to this). We can release / branch
> per component or from the root (still to be decided, but completely
> orthogonal to the problem)
I think we need to be able to articulate some clear 'rules' on versions.
> * use the model that felix / sling follows and have a versioning
> scheme per bundle with no way to maintain bug fix branches. Each
> bundle has to be released independantly with its own release notes and
> all. I think we'd have to flatten our svn tree as there's no real
> need to have a tree of modules (we can use maven profiles if we want
> to build only a given component). The consequence is that we also
> need to maintain documentation about compatiblity, as users see the
> bundle versions, not really the package versions and we need to have a
> way to tell them which bundles are supposed to work together (i think
> we have more than 100 bundles in the whole tree I think, so not sure
> what kind of documentation could give an overview of that ;-) ).
So, just to consider blueprint, which currently has 12 bundles, we would
- release each bundle separately, with its own vote. Its own JIRA
component, its own release notes, its own release announce etc.
- say we have blueprint-something at version x.y.z-SNAPSHOT, and we
want to release version x.y.z. In trunk there is also
blueprint-anotherthing at version a.b.c-SNAPSHOT. If we release
blueprint-something x.y.z, what do we say about what it has been
built/tested with? Or maybe we have to release blueprint-anotherthing
a.b.c at the same time?
> It seems any in-between solution has some big problems. Currently,
> we're more on the first solution and I think it's way easier for us
> and for our users.
It's easier for us. But what we do at the moment is definitely wrong wrt
to package versions. Is the implication of what you say above that you
believe we should not use semantic versioning (strictly) for packages?
Or do you think we can achieve this with some modifications to the
current process? That's what I was trying to explore. Independent bundle
releases does not seem practical (for us) unless we opted to combine
everything in a single uber bundle (and I think there were arguments
against that).
Zoe
> On Sat, Feb 5, 2011 at 11:03, Felix Meschberger<fm...@gmail.com> wrote:
>> Hi,
>>
>> Am Samstag, den 05.02.2011, 00:43 +0100 schrieb Guillaume Nodet:
>>>> In fact I want it to be easy, the easier the better. If you change the code the version should increment.
>>> So why even bother with having to manually change the version ? I
>>> think it should be possible to have the maven-bundle-plugin increment
>>> the version depending on the kind of changes by comparing the package
>>> signatures and make sure it follows the semantic versioning. Given it
>>> has already been done (see
>>> https://www.assembla.com/wiki/show/obcc/OSGi_Version_Generator) I
>>> think we could add that to the maven bundle plugin.
>> +1 !
>>
>> (Not sure, whether the Bundle Plugin does not get overloaded, though)
>>
>>>
>>> However, there's something which is worrying me about the semantic
>>> versioning. I don't think it can cope with maintenance branches. The
>>> process of incrementing a package version works well in a single line
>>> of releases, but not in a tree, so can't ever release a package which
>>> doesn't contain all the previous changes. Or rather the process works
>>> for a given package, but the problem is that our bundles do not only
>>> contain a single package. Let's take a concrete example.
>>> I have a bundle version 3.0 which has two packages foo / 1.0 + bar / 1.0.
>>> In a future release 3.1 of that bundle, i add one functionality to the
>>> foo package and a minor modification to the bar package, so I release
>>> this with foo / 1.1 + bar / 1.0.1.
>>> Some time later, I find a bug in the bar package which I'd like to fix
>>> for both minor versions of my bundle. If I do so, I'd end up with a
>>> bundle 3.0.1 with foo / 1.0 + bar / 1.0.1 and a bundle 3.1.1 with foo
>>> / 1.1 + bar / 1.0.2. That's not really possible because the two bar /
>>> 1.0.1 package would be different.
>>> Possible solutions:
>>> * backport into 3.0 branch the change that modification that caused
>>> the bump from 1.0 to 1.0.1 (when releasing 3.1). However, this may
>>> not be a big fix, maybe a small improvement that I don't want to
>>> backport, so I don't think this solution is a good idea
>>> * never release a bundle which exports multiple packages: that sucks too
>>> * don't do maintenance release: i don't think we want that
>>> * consider that any modification you may not want to backport in a
>>> maintenance branch later should lead to bump the minor version of a
>>> package, even if the signature of the package doesn't really change
>>> I think the last one is the only one applicable. Thoughts ?
>> Well branches pose just more than this single problem, which is why I
>> generally try to avoid release branches like the plague ...
>>
>> In this concrete example, you might probably have to either backport
>> everything from the bar/1.0.1 package or employ qualifier increments.
>>
>> At the end of the day, this should not prevent the project from adopting
>> semantic versioning, because the benefits tremendously outweigh these
>> minor costs.
>>
>> Regards
>> Felix
>>
>>>
>>>>> On the other hand, the problem is always the same: you have to update
>>>>> information in a secondary location -- regardless of whether this is the
>>>>> packaginfo or the pom.xml file.
>>>>>
>>>> Right, and packageinfo is right next to the classes you just updated, closer = better IMHO.
>>>>
>>>>> The advantage of doing it in the pom.xml file IMHO is that you have a
>>>>> complete overview of your exports incl. their versions. YMMV.
>>>>>
>>>> The downside in our case is you have to update the bundle and the uber bundle, bigger chance of getting out of sync, which would be very very bad.
>>>>
>>>>>> also you need to sync the version correctly
>>>>>> between the bundles
>>>>> the bundle plugin takes care of this (fortunately) -- assuming you mean
>>>>> the "Import-Package" versioning.
>>>>>
>>>> I'm trying to address export bundle. I'm happy with the import package stuff.
>>>>
>>>>>> and the uber bundles.
>>>>>> bnd supports the packageinfo files (and also annotations in
>>>>>> package-info.java), but those are not currently picked up and used in
>>>>>> our build. I raise FELIX-2819 and a workaround has been suggested,
>>>>>> which I managed to get working.
>>>>>>
>>>>>> The fix would be to add the following to the default-pom and get the
>>>>>> modules to use the updated parent:
>>>>>>
>>>>>> <resource>
>>>>>> <directory>${project.build.sourceDirectory}</directory>
>>>>>> <includes>
>>>>>> <include>**/packageinfo</include>
>>>>>> </includes>
>>>>>> </resource>
>>>>> Unfortunately, you will still have the regular resources in the
>>>>> src/main/resources tree. So you have to explicitly list this to in the
>>>>> <resources> element of the parent POM to not miss these...
>>>> Right, this is already in our parent pom, so I'm proposing adding this in addition to the other resources statements already there.
>>>>
>>>>> In Sling we currently maintain the exported package version in the POMs.
>>>>> This works fine but is also kind of suboptimal.
>>>>>
>>>>> I think the most important thing is to make it consistent: Do it either
>>>>> way, but stick to.
>>>> I agree. I think we should use packageinfo though :)
>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>>> Thoughts?
>>>>>> Alasdair
>>>>>>
>>>>>
>>>
>>>
>>
>>
>
>
RE: [DISCUSSION] Using packageinfo to set package versions
Posted by Timothy Ward <ti...@apache.org>.
> I think we may want to stick too much to semantic versioning. Don't
> get me wrong, I agree with the compatibility rules semantic and we
> should support them: i.e. if there is an incompatible change, the
> major version has to be different and if there is a compatible change,
> the minor version has to be different.
> However, I think it does not imply we need to be strict about *when*
> we change the version of the package. If we align the package version
> changes with the bundle version changes (that does not necessarily
> imply they have to be the same), i.e. when we change from aries 0.3 to
> aries 0.4, the packages are bumped too from a minor version, this
> leaves some place to do branch fixes using minor versions on the
> package.
I am a strong -1 for this. Doing this means that you can't mix bundles from different releases and you can't reliably write a plugin for our projects. If we start incrementing package versions for no reason then people who implement our APIs will be broken by every release.
Regards,
Tim
----------------------------------------
> Date: Sat, 5 Feb 2011 13:38:42 +0100
> Subject: Re: [DISCUSSION] Using packageinfo to set package versions
> From: gnodet@gmail.com
> To: dev@aries.apache.org
>
> I think we may want to stick too much to semantic versioning. Don't
> get me wrong, I agree with the compatibility rules semantic and we
> should support them: i.e. if there is an incompatible change, the
> major version has to be different and if there is a compatible change,
> the minor version has to be different.
> However, I think it does not imply we need to be strict about *when*
> we change the version of the package. If we align the package version
> changes with the bundle version changes (that does not necessarily
> imply they have to be the same), i.e. when we change from aries 0.3 to
> aries 0.4, the packages are bumped too from a minor version, this
> leaves some place to do branch fixes using minor versions on the
> package.
>
> I think we face two different development model basically:
>
> * use a more traditional development model using a tree of versions
> (either at the component level or for the whole tree). We can support
> branch fixes and micro releases in a tree. We need to somewhat align
> the package version changes to the bundle version change. This means
> we may end up with multiple identical packages with the same version
> number (though I suppose real api and library packages are somewhat
> different, as pure API packages that do not contain any code could
> have their own versioning not tied to this). We can release / branch
> per component or from the root (still to be decided, but completely
> orthogonal to the problem)
>
> * use the model that felix / sling follows and have a versioning
> scheme per bundle with no way to maintain bug fix branches. Each
> bundle has to be released independantly with its own release notes and
> all. I think we'd have to flatten our svn tree as there's no real
> need to have a tree of modules (we can use maven profiles if we want
> to build only a given component). The consequence is that we also
> need to maintain documentation about compatiblity, as users see the
> bundle versions, not really the package versions and we need to have a
> way to tell them which bundles are supposed to work together (i think
> we have more than 100 bundles in the whole tree I think, so not sure
> what kind of documentation could give an overview of that ;-) ).
>
> It seems any in-between solution has some big problems. Currently,
> we're more on the first solution and I think it's way easier for us
> and for our users.
>
> On Sat, Feb 5, 2011 at 11:03, Felix Meschberger wrote:
> > Hi,
> >
> > Am Samstag, den 05.02.2011, 00:43 +0100 schrieb Guillaume Nodet:
> >> > In fact I want it to be easy, the easier the better. If you change the code the version should increment.
> >>
> >> So why even bother with having to manually change the version ? I
> >> think it should be possible to have the maven-bundle-plugin increment
> >> the version depending on the kind of changes by comparing the package
> >> signatures and make sure it follows the semantic versioning. Given it
> >> has already been done (see
> >> https://www.assembla.com/wiki/show/obcc/OSGi_Version_Generator) I
> >> think we could add that to the maven bundle plugin.
> >
> > +1 !
> >
> > (Not sure, whether the Bundle Plugin does not get overloaded, though)
> >
> >>
> >>
> >> However, there's something which is worrying me about the semantic
> >> versioning. I don't think it can cope with maintenance branches. The
> >> process of incrementing a package version works well in a single line
> >> of releases, but not in a tree, so can't ever release a package which
> >> doesn't contain all the previous changes. Or rather the process works
> >> for a given package, but the problem is that our bundles do not only
> >> contain a single package. Let's take a concrete example.
> >> I have a bundle version 3.0 which has two packages foo / 1.0 + bar / 1.0.
> >> In a future release 3.1 of that bundle, i add one functionality to the
> >> foo package and a minor modification to the bar package, so I release
> >> this with foo / 1.1 + bar / 1.0.1.
> >> Some time later, I find a bug in the bar package which I'd like to fix
> >> for both minor versions of my bundle. If I do so, I'd end up with a
> >> bundle 3.0.1 with foo / 1.0 + bar / 1.0.1 and a bundle 3.1.1 with foo
> >> / 1.1 + bar / 1.0.2. That's not really possible because the two bar /
> >> 1.0.1 package would be different.
> >> Possible solutions:
> >> * backport into 3.0 branch the change that modification that caused
> >> the bump from 1.0 to 1.0.1 (when releasing 3.1). However, this may
> >> not be a big fix, maybe a small improvement that I don't want to
> >> backport, so I don't think this solution is a good idea
> >> * never release a bundle which exports multiple packages: that sucks too
> >> * don't do maintenance release: i don't think we want that
> >> * consider that any modification you may not want to backport in a
> >> maintenance branch later should lead to bump the minor version of a
> >> package, even if the signature of the package doesn't really change
> >> I think the last one is the only one applicable. Thoughts ?
> >
> > Well branches pose just more than this single problem, which is why I
> > generally try to avoid release branches like the plague ...
> >
> > In this concrete example, you might probably have to either backport
> > everything from the bar/1.0.1 package or employ qualifier increments.
> >
> > At the end of the day, this should not prevent the project from adopting
> > semantic versioning, because the benefits tremendously outweigh these
> > minor costs.
> >
> > Regards
> > Felix
> >
> >>
> >>
> >> >> On the other hand, the problem is always the same: you have to update
> >> >> information in a secondary location -- regardless of whether this is the
> >> >> packaginfo or the pom.xml file.
> >> >>
> >> >
> >> > Right, and packageinfo is right next to the classes you just updated, closer = better IMHO.
> >> >
> >> >> The advantage of doing it in the pom.xml file IMHO is that you have a
> >> >> complete overview of your exports incl. their versions. YMMV.
> >> >>
> >> >
> >> > The downside in our case is you have to update the bundle and the uber bundle, bigger chance of getting out of sync, which would be very very bad.
> >> >
> >> >>> also you need to sync the version correctly
> >> >>> between the bundles
> >> >>
> >> >> the bundle plugin takes care of this (fortunately) -- assuming you mean
> >> >> the "Import-Package" versioning.
> >> >>
> >> >
> >> > I'm trying to address export bundle. I'm happy with the import package stuff.
> >> >
> >> >>> and the uber bundles.
> >> >>
> >> >>>
> >> >>> bnd supports the packageinfo files (and also annotations in
> >> >>> package-info.java), but those are not currently picked up and used in
> >> >>> our build. I raise FELIX-2819 and a workaround has been suggested,
> >> >>> which I managed to get working.
> >> >>>
> >> >>> The fix would be to add the following to the default-pom and get the
> >> >>> modules to use the updated parent:
> >> >>>
> >> >>>
> >> >>> ${project.build.sourceDirectory}
> >> >>>
> >> >>> **/packageinfo
> >> >>>
> >> >>>
> >> >>
> >> >> Unfortunately, you will still have the regular resources in the
> >> >> src/main/resources tree. So you have to explicitly list this to in the
> >> >> element of the parent POM to not miss these...
> >> >
> >> > Right, this is already in our parent pom, so I'm proposing adding this in addition to the other resources statements already there.
> >> >
> >> >>
> >> >> In Sling we currently maintain the exported package version in the POMs.
> >> >> This works fine but is also kind of suboptimal.
> >> >>
> >> >> I think the most important thing is to make it consistent: Do it either
> >> >> way, but stick to.
> >> >
> >> > I agree. I think we should use packageinfo though :)
> >> >
> >> >>
> >> >> Regards
> >> >> Felix
> >> >>
> >> >>>
> >> >>> Thoughts?
> >> >>> Alasdair
> >> >>>
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >
> >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: [DISCUSSION] Using packageinfo to set package versions
Posted by Guillaume Nodet <gn...@gmail.com>.
I think we may want to stick too much to semantic versioning. Don't
get me wrong, I agree with the compatibility rules semantic and we
should support them: i.e. if there is an incompatible change, the
major version has to be different and if there is a compatible change,
the minor version has to be different.
However, I think it does not imply we need to be strict about *when*
we change the version of the package. If we align the package version
changes with the bundle version changes (that does not necessarily
imply they have to be the same), i.e. when we change from aries 0.3 to
aries 0.4, the packages are bumped too from a minor version, this
leaves some place to do branch fixes using minor versions on the
package.
I think we face two different development model basically:
* use a more traditional development model using a tree of versions
(either at the component level or for the whole tree). We can support
branch fixes and micro releases in a tree. We need to somewhat align
the package version changes to the bundle version change. This means
we may end up with multiple identical packages with the same version
number (though I suppose real api and library packages are somewhat
different, as pure API packages that do not contain any code could
have their own versioning not tied to this). We can release / branch
per component or from the root (still to be decided, but completely
orthogonal to the problem)
* use the model that felix / sling follows and have a versioning
scheme per bundle with no way to maintain bug fix branches. Each
bundle has to be released independantly with its own release notes and
all. I think we'd have to flatten our svn tree as there's no real
need to have a tree of modules (we can use maven profiles if we want
to build only a given component). The consequence is that we also
need to maintain documentation about compatiblity, as users see the
bundle versions, not really the package versions and we need to have a
way to tell them which bundles are supposed to work together (i think
we have more than 100 bundles in the whole tree I think, so not sure
what kind of documentation could give an overview of that ;-) ).
It seems any in-between solution has some big problems. Currently,
we're more on the first solution and I think it's way easier for us
and for our users.
On Sat, Feb 5, 2011 at 11:03, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Am Samstag, den 05.02.2011, 00:43 +0100 schrieb Guillaume Nodet:
>> > In fact I want it to be easy, the easier the better. If you change the code the version should increment.
>>
>> So why even bother with having to manually change the version ? I
>> think it should be possible to have the maven-bundle-plugin increment
>> the version depending on the kind of changes by comparing the package
>> signatures and make sure it follows the semantic versioning. Given it
>> has already been done (see
>> https://www.assembla.com/wiki/show/obcc/OSGi_Version_Generator) I
>> think we could add that to the maven bundle plugin.
>
> +1 !
>
> (Not sure, whether the Bundle Plugin does not get overloaded, though)
>
>>
>>
>> However, there's something which is worrying me about the semantic
>> versioning. I don't think it can cope with maintenance branches. The
>> process of incrementing a package version works well in a single line
>> of releases, but not in a tree, so can't ever release a package which
>> doesn't contain all the previous changes. Or rather the process works
>> for a given package, but the problem is that our bundles do not only
>> contain a single package. Let's take a concrete example.
>> I have a bundle version 3.0 which has two packages foo / 1.0 + bar / 1.0.
>> In a future release 3.1 of that bundle, i add one functionality to the
>> foo package and a minor modification to the bar package, so I release
>> this with foo / 1.1 + bar / 1.0.1.
>> Some time later, I find a bug in the bar package which I'd like to fix
>> for both minor versions of my bundle. If I do so, I'd end up with a
>> bundle 3.0.1 with foo / 1.0 + bar / 1.0.1 and a bundle 3.1.1 with foo
>> / 1.1 + bar / 1.0.2. That's not really possible because the two bar /
>> 1.0.1 package would be different.
>> Possible solutions:
>> * backport into 3.0 branch the change that modification that caused
>> the bump from 1.0 to 1.0.1 (when releasing 3.1). However, this may
>> not be a big fix, maybe a small improvement that I don't want to
>> backport, so I don't think this solution is a good idea
>> * never release a bundle which exports multiple packages: that sucks too
>> * don't do maintenance release: i don't think we want that
>> * consider that any modification you may not want to backport in a
>> maintenance branch later should lead to bump the minor version of a
>> package, even if the signature of the package doesn't really change
>> I think the last one is the only one applicable. Thoughts ?
>
> Well branches pose just more than this single problem, which is why I
> generally try to avoid release branches like the plague ...
>
> In this concrete example, you might probably have to either backport
> everything from the bar/1.0.1 package or employ qualifier increments.
>
> At the end of the day, this should not prevent the project from adopting
> semantic versioning, because the benefits tremendously outweigh these
> minor costs.
>
> Regards
> Felix
>
>>
>>
>> >> On the other hand, the problem is always the same: you have to update
>> >> information in a secondary location -- regardless of whether this is the
>> >> packaginfo or the pom.xml file.
>> >>
>> >
>> > Right, and packageinfo is right next to the classes you just updated, closer = better IMHO.
>> >
>> >> The advantage of doing it in the pom.xml file IMHO is that you have a
>> >> complete overview of your exports incl. their versions. YMMV.
>> >>
>> >
>> > The downside in our case is you have to update the bundle and the uber bundle, bigger chance of getting out of sync, which would be very very bad.
>> >
>> >>> also you need to sync the version correctly
>> >>> between the bundles
>> >>
>> >> the bundle plugin takes care of this (fortunately) -- assuming you mean
>> >> the "Import-Package" versioning.
>> >>
>> >
>> > I'm trying to address export bundle. I'm happy with the import package stuff.
>> >
>> >>> and the uber bundles.
>> >>
>> >>>
>> >>> bnd supports the packageinfo files (and also annotations in
>> >>> package-info.java), but those are not currently picked up and used in
>> >>> our build. I raise FELIX-2819 and a workaround has been suggested,
>> >>> which I managed to get working.
>> >>>
>> >>> The fix would be to add the following to the default-pom and get the
>> >>> modules to use the updated parent:
>> >>>
>> >>> <resource>
>> >>> <directory>${project.build.sourceDirectory}</directory>
>> >>> <includes>
>> >>> <include>**/packageinfo</include>
>> >>> </includes>
>> >>> </resource>
>> >>
>> >> Unfortunately, you will still have the regular resources in the
>> >> src/main/resources tree. So you have to explicitly list this to in the
>> >> <resources> element of the parent POM to not miss these...
>> >
>> > Right, this is already in our parent pom, so I'm proposing adding this in addition to the other resources statements already there.
>> >
>> >>
>> >> In Sling we currently maintain the exported package version in the POMs.
>> >> This works fine but is also kind of suboptimal.
>> >>
>> >> I think the most important thing is to make it consistent: Do it either
>> >> way, but stick to.
>> >
>> > I agree. I think we should use packageinfo though :)
>> >
>> >>
>> >> Regards
>> >> Felix
>> >>
>> >>>
>> >>> Thoughts?
>> >>> Alasdair
>> >>>
>> >>
>> >>
>> >
>>
>>
>>
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSSION] Using packageinfo to set package versions
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Samstag, den 05.02.2011, 00:43 +0100 schrieb Guillaume Nodet:
> > In fact I want it to be easy, the easier the better. If you change the code the version should increment.
>
> So why even bother with having to manually change the version ? I
> think it should be possible to have the maven-bundle-plugin increment
> the version depending on the kind of changes by comparing the package
> signatures and make sure it follows the semantic versioning. Given it
> has already been done (see
> https://www.assembla.com/wiki/show/obcc/OSGi_Version_Generator) I
> think we could add that to the maven bundle plugin.
+1 !
(Not sure, whether the Bundle Plugin does not get overloaded, though)
>
>
> However, there's something which is worrying me about the semantic
> versioning. I don't think it can cope with maintenance branches. The
> process of incrementing a package version works well in a single line
> of releases, but not in a tree, so can't ever release a package which
> doesn't contain all the previous changes. Or rather the process works
> for a given package, but the problem is that our bundles do not only
> contain a single package. Let's take a concrete example.
> I have a bundle version 3.0 which has two packages foo / 1.0 + bar / 1.0.
> In a future release 3.1 of that bundle, i add one functionality to the
> foo package and a minor modification to the bar package, so I release
> this with foo / 1.1 + bar / 1.0.1.
> Some time later, I find a bug in the bar package which I'd like to fix
> for both minor versions of my bundle. If I do so, I'd end up with a
> bundle 3.0.1 with foo / 1.0 + bar / 1.0.1 and a bundle 3.1.1 with foo
> / 1.1 + bar / 1.0.2. That's not really possible because the two bar /
> 1.0.1 package would be different.
> Possible solutions:
> * backport into 3.0 branch the change that modification that caused
> the bump from 1.0 to 1.0.1 (when releasing 3.1). However, this may
> not be a big fix, maybe a small improvement that I don't want to
> backport, so I don't think this solution is a good idea
> * never release a bundle which exports multiple packages: that sucks too
> * don't do maintenance release: i don't think we want that
> * consider that any modification you may not want to backport in a
> maintenance branch later should lead to bump the minor version of a
> package, even if the signature of the package doesn't really change
> I think the last one is the only one applicable. Thoughts ?
Well branches pose just more than this single problem, which is why I
generally try to avoid release branches like the plague ...
In this concrete example, you might probably have to either backport
everything from the bar/1.0.1 package or employ qualifier increments.
At the end of the day, this should not prevent the project from adopting
semantic versioning, because the benefits tremendously outweigh these
minor costs.
Regards
Felix
>
>
> >> On the other hand, the problem is always the same: you have to update
> >> information in a secondary location -- regardless of whether this is the
> >> packaginfo or the pom.xml file.
> >>
> >
> > Right, and packageinfo is right next to the classes you just updated, closer = better IMHO.
> >
> >> The advantage of doing it in the pom.xml file IMHO is that you have a
> >> complete overview of your exports incl. their versions. YMMV.
> >>
> >
> > The downside in our case is you have to update the bundle and the uber bundle, bigger chance of getting out of sync, which would be very very bad.
> >
> >>> also you need to sync the version correctly
> >>> between the bundles
> >>
> >> the bundle plugin takes care of this (fortunately) -- assuming you mean
> >> the "Import-Package" versioning.
> >>
> >
> > I'm trying to address export bundle. I'm happy with the import package stuff.
> >
> >>> and the uber bundles.
> >>
> >>>
> >>> bnd supports the packageinfo files (and also annotations in
> >>> package-info.java), but those are not currently picked up and used in
> >>> our build. I raise FELIX-2819 and a workaround has been suggested,
> >>> which I managed to get working.
> >>>
> >>> The fix would be to add the following to the default-pom and get the
> >>> modules to use the updated parent:
> >>>
> >>> <resource>
> >>> <directory>${project.build.sourceDirectory}</directory>
> >>> <includes>
> >>> <include>**/packageinfo</include>
> >>> </includes>
> >>> </resource>
> >>
> >> Unfortunately, you will still have the regular resources in the
> >> src/main/resources tree. So you have to explicitly list this to in the
> >> <resources> element of the parent POM to not miss these...
> >
> > Right, this is already in our parent pom, so I'm proposing adding this in addition to the other resources statements already there.
> >
> >>
> >> In Sling we currently maintain the exported package version in the POMs.
> >> This works fine but is also kind of suboptimal.
> >>
> >> I think the most important thing is to make it consistent: Do it either
> >> way, but stick to.
> >
> > I agree. I think we should use packageinfo though :)
> >
> >>
> >> Regards
> >> Felix
> >>
> >>>
> >>> Thoughts?
> >>> Alasdair
> >>>
> >>
> >>
> >
>
>
>
Re: [DISCUSSION] Using packageinfo to set package versions
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Feb 4, 2011 at 23:41, Alasdair Nottingham <no...@apache.org> wrote:
>
>
> Alasdair Nottingham
>
> On 4 Feb 2011, at 22:13, Felix Meschberger <fm...@gmail.com> wrote:
>
>> Hi,
>>
>> Am Freitag, den 04.02.2011, 21:33 +0000 schrieb Alasdair Nottingham:
>>> Hi,
>>>
>>> Currently we specify versions of exported packages in the pom. This is
>>> not ideal as it means whenever anyone makes a change in a package they
>>> have to edit the pom,
>>
>> You could argue that modifying exported packages is critical, so making
>> it harder to do might get people to think twice ... Granted this is kind
>> of a weak argument ;-)
>>
>
> In fact I want it to be easy, the easier the better. If you change the code the version should increment.
So why even bother with having to manually change the version ? I
think it should be possible to have the maven-bundle-plugin increment
the version depending on the kind of changes by comparing the package
signatures and make sure it follows the semantic versioning. Given it
has already been done (see
https://www.assembla.com/wiki/show/obcc/OSGi_Version_Generator) I
think we could add that to the maven bundle plugin.
However, there's something which is worrying me about the semantic
versioning. I don't think it can cope with maintenance branches. The
process of incrementing a package version works well in a single line
of releases, but not in a tree, so can't ever release a package which
doesn't contain all the previous changes. Or rather the process works
for a given package, but the problem is that our bundles do not only
contain a single package. Let's take a concrete example.
I have a bundle version 3.0 which has two packages foo / 1.0 + bar / 1.0.
In a future release 3.1 of that bundle, i add one functionality to the
foo package and a minor modification to the bar package, so I release
this with foo / 1.1 + bar / 1.0.1.
Some time later, I find a bug in the bar package which I'd like to fix
for both minor versions of my bundle. If I do so, I'd end up with a
bundle 3.0.1 with foo / 1.0 + bar / 1.0.1 and a bundle 3.1.1 with foo
/ 1.1 + bar / 1.0.2. That's not really possible because the two bar /
1.0.1 package would be different.
Possible solutions:
* backport into 3.0 branch the change that modification that caused
the bump from 1.0 to 1.0.1 (when releasing 3.1). However, this may
not be a big fix, maybe a small improvement that I don't want to
backport, so I don't think this solution is a good idea
* never release a bundle which exports multiple packages: that sucks too
* don't do maintenance release: i don't think we want that
* consider that any modification you may not want to backport in a
maintenance branch later should lead to bump the minor version of a
package, even if the signature of the package doesn't really change
I think the last one is the only one applicable. Thoughts ?
>> On the other hand, the problem is always the same: you have to update
>> information in a secondary location -- regardless of whether this is the
>> packaginfo or the pom.xml file.
>>
>
> Right, and packageinfo is right next to the classes you just updated, closer = better IMHO.
>
>> The advantage of doing it in the pom.xml file IMHO is that you have a
>> complete overview of your exports incl. their versions. YMMV.
>>
>
> The downside in our case is you have to update the bundle and the uber bundle, bigger chance of getting out of sync, which would be very very bad.
>
>>> also you need to sync the version correctly
>>> between the bundles
>>
>> the bundle plugin takes care of this (fortunately) -- assuming you mean
>> the "Import-Package" versioning.
>>
>
> I'm trying to address export bundle. I'm happy with the import package stuff.
>
>>> and the uber bundles.
>>
>>>
>>> bnd supports the packageinfo files (and also annotations in
>>> package-info.java), but those are not currently picked up and used in
>>> our build. I raise FELIX-2819 and a workaround has been suggested,
>>> which I managed to get working.
>>>
>>> The fix would be to add the following to the default-pom and get the
>>> modules to use the updated parent:
>>>
>>> <resource>
>>> <directory>${project.build.sourceDirectory}</directory>
>>> <includes>
>>> <include>**/packageinfo</include>
>>> </includes>
>>> </resource>
>>
>> Unfortunately, you will still have the regular resources in the
>> src/main/resources tree. So you have to explicitly list this to in the
>> <resources> element of the parent POM to not miss these...
>
> Right, this is already in our parent pom, so I'm proposing adding this in addition to the other resources statements already there.
>
>>
>> In Sling we currently maintain the exported package version in the POMs.
>> This works fine but is also kind of suboptimal.
>>
>> I think the most important thing is to make it consistent: Do it either
>> way, but stick to.
>
> I agree. I think we should use packageinfo though :)
>
>>
>> Regards
>> Felix
>>
>>>
>>> Thoughts?
>>> Alasdair
>>>
>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSSION] Using packageinfo to set package versions
Posted by Alasdair Nottingham <no...@apache.org>.
Alasdair Nottingham
On 4 Feb 2011, at 22:13, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Am Freitag, den 04.02.2011, 21:33 +0000 schrieb Alasdair Nottingham:
>> Hi,
>>
>> Currently we specify versions of exported packages in the pom. This is
>> not ideal as it means whenever anyone makes a change in a package they
>> have to edit the pom,
>
> You could argue that modifying exported packages is critical, so making
> it harder to do might get people to think twice ... Granted this is kind
> of a weak argument ;-)
>
In fact I want it to be easy, the easier the better. If you change the code the version should increment.
> On the other hand, the problem is always the same: you have to update
> information in a secondary location -- regardless of whether this is the
> packaginfo or the pom.xml file.
>
Right, and packageinfo is right next to the classes you just updated, closer = better IMHO.
> The advantage of doing it in the pom.xml file IMHO is that you have a
> complete overview of your exports incl. their versions. YMMV.
>
The downside in our case is you have to update the bundle and the uber bundle, bigger chance of getting out of sync, which would be very very bad.
>> also you need to sync the version correctly
>> between the bundles
>
> the bundle plugin takes care of this (fortunately) -- assuming you mean
> the "Import-Package" versioning.
>
I'm trying to address export bundle. I'm happy with the import package stuff.
>> and the uber bundles.
>
>>
>> bnd supports the packageinfo files (and also annotations in
>> package-info.java), but those are not currently picked up and used in
>> our build. I raise FELIX-2819 and a workaround has been suggested,
>> which I managed to get working.
>>
>> The fix would be to add the following to the default-pom and get the
>> modules to use the updated parent:
>>
>> <resource>
>> <directory>${project.build.sourceDirectory}</directory>
>> <includes>
>> <include>**/packageinfo</include>
>> </includes>
>> </resource>
>
> Unfortunately, you will still have the regular resources in the
> src/main/resources tree. So you have to explicitly list this to in the
> <resources> element of the parent POM to not miss these...
Right, this is already in our parent pom, so I'm proposing adding this in addition to the other resources statements already there.
>
> In Sling we currently maintain the exported package version in the POMs.
> This works fine but is also kind of suboptimal.
>
> I think the most important thing is to make it consistent: Do it either
> way, but stick to.
I agree. I think we should use packageinfo though :)
>
> Regards
> Felix
>
>>
>> Thoughts?
>> Alasdair
>>
>
>
Re: [DISCUSSION] Using packageinfo to set package versions
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Freitag, den 04.02.2011, 21:33 +0000 schrieb Alasdair Nottingham:
> Hi,
>
> Currently we specify versions of exported packages in the pom. This is
> not ideal as it means whenever anyone makes a change in a package they
> have to edit the pom,
You could argue that modifying exported packages is critical, so making
it harder to do might get people to think twice ... Granted this is kind
of a weak argument ;-)
On the other hand, the problem is always the same: you have to update
information in a secondary location -- regardless of whether this is the
packaginfo or the pom.xml file.
The advantage of doing it in the pom.xml file IMHO is that you have a
complete overview of your exports incl. their versions. YMMV.
> also you need to sync the version correctly
> between the bundles
the bundle plugin takes care of this (fortunately) -- assuming you mean
the "Import-Package" versioning.
> and the uber bundles.
>
> bnd supports the packageinfo files (and also annotations in
> package-info.java), but those are not currently picked up and used in
> our build. I raise FELIX-2819 and a workaround has been suggested,
> which I managed to get working.
>
> The fix would be to add the following to the default-pom and get the
> modules to use the updated parent:
>
> <resource>
> <directory>${project.build.sourceDirectory}</directory>
> <includes>
> <include>**/packageinfo</include>
> </includes>
> </resource>
Unfortunately, you will still have the regular resources in the
src/main/resources tree. So you have to explicitly list this to in the
<resources> element of the parent POM to not miss these...
In Sling we currently maintain the exported package version in the POMs.
This works fine but is also kind of suboptimal.
I think the most important thing is to make it consistent: Do it either
way, but stick to.
Regards
Felix
>
> Thoughts?
> Alasdair
>