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/01/31 12:17:59 UTC
Release by module - changes to trunk
Hi all
Now that we have a 0.3 release I plan to change trunk so that where
modules depend on other Aries modules the depend on the released
versions and _not_ versions in trunk.
This will mean:
(a) The current development version will be 0.4-SNAPSHOT
(b) All Aries 0.4-SNAPSHOT modules will depend on 0.3 parent.
(c) Where an Aries module depends on other Aries modules, it will depend
on the released versions of the other modules _until_ it requires a
change in the module that it depends on, at which stage it will switch
to a dependency on the development version.
So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3, proxy
0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs to
pick up a change in proxy the blueprint top level pom will need to be
modified to point to proxy 0.4-SNAPSHOT.
This will lead us towards being able to release by module but it implies
a change in development practice. I will make the pom changes locally
and test them but I'd like to check that release-by-module is still the
goal and that you all think this is a reasonable way to be able to
achieve it.
Zoë
Re: Release by module - changes to trunk
Posted by zoe slattery <zo...@gmail.com>.
Hi
>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3, proxy
>> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs to
>> pick up a change in proxy the blueprint top level pom will need to be
>> modified to point to proxy 0.4-SNAPSHOT.
> Subsequently when releasing Blueprint 0.4, proxy 0.4 would also have
> to be released before or at the same time.
Yes, that's right. As long as we keep the dependencies in the top level
pom for the project it should always be obvious what else needs to be
released.
I am doing a bit of commenting in the poms as I go along.
>>
>> Zoė
>>
>>
>>
>>
Re: Release by module - changes to trunk
Posted by Jeremy Hughes <hu...@apache.org>.
On 31 January 2011 11:17, zoe slattery <zo...@gmail.com> wrote:
> Hi all
>
> Now that we have a 0.3 release I plan to change trunk so that where modules
> depend on other Aries modules the depend on the released versions and _not_
> versions in trunk.
>
> This will mean:
>
> (a) The current development version will be 0.4-SNAPSHOT
> (b) All Aries 0.4-SNAPSHOT modules will depend on 0.3 parent.
> (c) Where an Aries module depends on other Aries modules, it will depend on
> the released versions of the other modules _until_ it requires a change in
> the module that it depends on, at which stage it will switch to a dependency
> on the development version.
> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3, proxy
> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs to
> pick up a change in proxy the blueprint top level pom will need to be
> modified to point to proxy 0.4-SNAPSHOT.
Subsequently when releasing Blueprint 0.4, proxy 0.4 would also have
to be released before or at the same time.
>
> This will lead us towards being able to release by module but it implies a
> change in development practice. I will make the pom changes locally and test
> them but I'd like to check that release-by-module is still the goal and that
> you all think this is a reasonable way to be able to achieve it.
+1 to these changes.
>
>
> Zoė
>
>
>
>
Re: Release by module - changes to trunk
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1, it makes sense.
AFAIK, there are some dependencies between some modules (if we release
one, we should release the other(s)). Maybe we have to document that or
organize POMs to manage it.
Regards
JB
On 01/31/2011 12:17 PM, zoe slattery wrote:
> Hi all
>
> Now that we have a 0.3 release I plan to change trunk so that where
> modules depend on other Aries modules the depend on the released
> versions and _not_ versions in trunk.
>
> This will mean:
>
> (a) The current development version will be 0.4-SNAPSHOT
> (b) All Aries 0.4-SNAPSHOT modules will depend on 0.3 parent.
> (c) Where an Aries module depends on other Aries modules, it will depend
> on the released versions of the other modules _until_ it requires a
> change in the module that it depends on, at which stage it will switch
> to a dependency on the development version.
> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3, proxy
> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs to
> pick up a change in proxy the blueprint top level pom will need to be
> modified to point to proxy 0.4-SNAPSHOT.
>
> This will lead us towards being able to release by module but it implies
> a change in development practice. I will make the pom changes locally
> and test them but I'd like to check that release-by-module is still the
> goal and that you all think this is a reasonable way to be able to
> achieve it.
>
>
> Zoë
>
>
>
Re: Release by module - changes to trunk
Posted by zoe slattery <zo...@gmail.com>.
In order to experiment with variations in:
-module versions
-bundle versions
-package versions
the best thing to do is to branch and play around in a branch, so I'll
do that now and and summarise my conclusions (if any :-) )
on the list.
Zoe
> On 1 February 2011 17:37, zoe slattery<zo...@gmail.com> wrote:
>> On 01/02/2011 17:03, Guillaume Nodet wrote:
>>> As I said in my previous mail, one possibility would be to split the
>>> release cycle and artifact versioning scheme from the osgi package
>>> versioning scheme.
>>> Which we already do to some degree when we release blueprint-bundle
>>> which contain the blueprint-api in version 1.0 and the implementation
>>> in version 0.3.
>>>
>> I think this is worth looking into.
>>> Honestly, given the hassle of releasing things, I think a single trunk
>>> + single release cycle is the easiest way to go. I think if we have
>>> a simple release process, we could release things more often and maybe
>>> maintain branches. I don't really see any problem in having
>>> blueprint-cm-0.4.0 being the same as blueprint-cm-0.4.1. But if it
>>> takes 2 days to one person to do a release, less people will volunteer
>>> to do those, which is imho worse, as we won't deliver fixes to our
>>> users.
>> The release process as it stands is actually very simple - and - though I
>> should probably not say it myself - it is well documented.
> FWIW I think it's good :-)
>
>> It took me a little time to do 0.3 but I had/chose to make fixes to a lot of
>> poms.
> if we'd had smaller more frequent releases it would have been done
> bit-by-bit and not taken a lot of time to do all in one go.
>
>> I worry a lot about making the development process more complex. The reason
>> that I was fixing poms for 0.3 is that one or two people didn't
>> understand the pom construction, also there were a few licences to fix.
>> Without these issues (which are completely avoidable
>> by putting comments in the poms and running rat in the build) it would
>> really be quite fast to release the whole of Aries.
> Take application 0.2.1 as an example - that happened very quickly.
> What takes the time is the 72 hours for the vote but that's not 72
> hours of working time, just elapsed time. Also, the need for 3 PMC
> members to vote (and hence have checked the release) - well if it's
> small it'll be quicker to check.
>
>> Making the development process complex will make it harder to remember - and
>> will likely make releasing harder because people won't remember
>> the development process and the release manager will then have to fix it.
>> Also, if it's so hard for us to think of what the process should be, isn't
>> that an indication that we are heading for something too complex?
>>
>> Zoe
>>
>>
>>
>>> On Tue, Feb 1, 2011 at 16:22, Jeremy Hughes<hu...@apache.org> wrote:
>>>> On 1 February 2011 14:54, Guillaume Nodet<gn...@gmail.com> wrote:
>>>>> This is very different from what we have I think, as gogo's root pom
>>>>> isn't used at all.
>>>>> Releasing gogo involves releasing each of the maven subproject
>>>>> independantly afaik.
>>>>>
>>>>> The main difference is that all felix releases consists of a *single*
>>>>> bundle. If we go this way, that would mean that releasing blueprint
>>>>> only would require 13 releases. Some of those just contain tests, so
>>>>> that does not make sense to me. From an usability point of view, I
>>>>> would definitely not go that way. I'd personaly rather go in the
>>>>> opposite direction and use a single reactor / release for all
>>>>> components.
>>>>>
>>>>> Another consideration is that I think we should tie the release cycle
>>>>> with the svn layout, i.e. if we want to keep each component with a
>>>>> separate lifecycle, we should have multiple trunks. That's way
>>>>> cleaner imho (and much more git friendly btw).
>>>> Lets discuss the multiple trunks idea a bit ... are you suggesting
>>>> something like:
>>>>
>>>> aries/application/branches
>>>> aries/application/tags
>>>> aries/application/trunk
>>>> aries/blueprint/branches
>>>> aries/blueprint/tags
>>>> aries/blueprint/trunk
>>>> etc
>>>>
>>>> We'd still be left with the multiproject issue - release blueprint
>>>> 0.3.1 for a single fix and all the blueprint bundles are released
>>>> whether they contain fixes or not. If each child of
>>>> aries/blueprint/trunk was only a single bundle (they are today, but
>>>> other top level modules like application would need some changes to
>>>> fit with this) ... then we could release each of them independently.
>>>>
>>>> But ... every time we release a bundle in blueprint we need to release
>>>> the 'uber' bundle - built from blueprint/blueprint-bundle. So, for
>>>> example, we would get to a situation where we release a fix to
>>>> blueprint-core @ 0.3.1 (and hence uber blueprint 0.3.1). Then
>>>> blueprint-cm needs a fix release - it's next micro number would be
>>>> 0.3.1 (we'd have to release uber blueprint @ 0.3.2).
>>>>
>>>> If blueprint-api then needs to release some additions to an interface,
>>>> then according to semantic versioning rules, it has broken
>>>> implementors of the interface, so its minor number goes up (to 0.4)
>>>> and of course blueprint-core implementing that would need to go up to
>>>> 0.4, and the uber blueprint bundle would go up to 0.4 too - but other
>>>> blueprint bundles wouldn't get released and hence stay at 0.3.
>>>>
>>>> This is a fairly complex process that we'd need to be careful to get
>>>> right.
>>>>
>>>>> On Tue, Feb 1, 2011 at 15:25, zoe slattery<zo...@gmail.com>
>>>>> wrote:
>>>>>> Hi Felix
>>>>>>
>>>>>> I had a look at felix to see if I could work out how you do the
>>>>>> independent
>>>>>> releases. I didn't look through absolutely everything but
>>>>>> I only found two modules that had sub-modules (gogo and http). Of those
>>>>>> two
>>>>>> it looks as though the pom structure in gogo might be similar
>>>>>> to what we need in Aries. Is this a model you would recommend? Or is
>>>>>> there
>>>>>> something closer?
>>>>>>
>>>>>> Zoe
>>>>>>> Hi,
>>>>>>>
>>>>>>> Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
>>>>>>>> Wouldn't that imply that each bundle has its own lifecycle ?
>>>>>>>> I think a while ago we agreed on having one release per "component",
>>>>>>>> i.e. blueprint (which includes api + core + cm + ...).
>>>>>>>> I'm not sure how well this would go if we have blueprint-core
>>>>>>>> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
>>>>>>> I bet you won't release blueprint-api as version 0.4.0 if it is the
>>>>>>> same
>>>>>>> as 0.3.0, right ?
>>>>>>>
>>>>>>> Regards
>>>>>>> Felix
>>>>>>>
>>>>>>>>> From a users point of view, it certainly does not help because all
>>>>>>>>> the
>>>>>>>> maven transitive dependencies are kinda screwed.
>>>>>>>>
>>>>>>>> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<fm...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
>>>>>>>>>>>> (c) Where an Aries module depends on other Aries modules, it will
>>>>>>>>>>>> depend
>>>>>>>>>>>> on the released versions of the other modules _until_ it requires
>>>>>>>>>>>> a
>>>>>>>>>>>> change in the module that it depends on, at which stage it will
>>>>>>>>>>>> switch
>>>>>>>>>>>> to a dependency on the development version.
>>>>>>>>>>>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce
>>>>>>>>>>>> 0.3,
>>>>>>>>>>>> proxy
>>>>>>>>>>>> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT
>>>>>>>>>>>> needs
>>>>>>>>>>>> to
>>>>>>>>>>>> pick up a change in proxy the blueprint top level pom will need
>>>>>>>>>>>> to be
>>>>>>>>>>>> modified to point to proxy 0.4-SNAPSHOT.
>>>>>>>>>>> I would assume this means "depends on modified API" and does not
>>>>>>>>>>> mean
>>>>>>>>>>> "depends on some bug fixed in the implementation", right ?
>>>>>>>>>> If you're referring to the semantic meaning attached to moving from
>>>>>>>>>> 0.3 to 0.4 then I think that would be taking this discussion in a
>>>>>>>>>> different direction. But that is a good point. Before getting into
>>>>>>>>>> a
>>>>>>>>>> semantic versioning discussion, I think the intent of this was to
>>>>>>>>>> so
>>>>>>>>>> if there are broken tests in 0.4-SNAPSHOT of a module which are
>>>>>>>>>> fixed
>>>>>>>>>> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
>>>>>>>>>> should be updated.
>>>>>>>>> No, this is not about semantic versioning (yet).
>>>>>>>>>
>>>>>>>>> This is about the following: Consider bundle X depends on the API
>>>>>>>>> org.apache.aries.y.api of bundle Y. Now some implementation of this
>>>>>>>>> API
>>>>>>>>> in package org.apache.aries.y.impl of bundle Y has a bug which must
>>>>>>>>> be
>>>>>>>>> fixed. In this case the dependency of bundle X on Y should not be
>>>>>>>>> changed.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Felix
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Felix
>>>>>>>>>>>
>>>>>>>>>>>> This will lead us towards being able to release by module but it
>>>>>>>>>>>> implies
>>>>>>>>>>>> a change in development practice. I will make the pom changes
>>>>>>>>>>>> locally
>>>>>>>>>>>> and test them but I'd like to check that release-by-module is
>>>>>>>>>>>> still
>>>>>>>>>>>> the
>>>>>>>>>>>> goal and that you all think this is a reasonable way to be able
>>>>>>>>>>>> to
>>>>>>>>>>>> achieve it.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Zoė
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>
>>
Re: Release by module - changes to trunk
Posted by Jeremy Hughes <hu...@apache.org>.
On 1 February 2011 17:37, zoe slattery <zo...@gmail.com> wrote:
> On 01/02/2011 17:03, Guillaume Nodet wrote:
>>
>> As I said in my previous mail, one possibility would be to split the
>> release cycle and artifact versioning scheme from the osgi package
>> versioning scheme.
>> Which we already do to some degree when we release blueprint-bundle
>> which contain the blueprint-api in version 1.0 and the implementation
>> in version 0.3.
>>
> I think this is worth looking into.
>>
>> Honestly, given the hassle of releasing things, I think a single trunk
>> + single release cycle is the easiest way to go. I think if we have
>> a simple release process, we could release things more often and maybe
>> maintain branches. I don't really see any problem in having
>> blueprint-cm-0.4.0 being the same as blueprint-cm-0.4.1. But if it
>> takes 2 days to one person to do a release, less people will volunteer
>> to do those, which is imho worse, as we won't deliver fixes to our
>> users.
>
> The release process as it stands is actually very simple - and - though I
> should probably not say it myself - it is well documented.
FWIW I think it's good :-)
> It took me a little time to do 0.3 but I had/chose to make fixes to a lot of
> poms.
if we'd had smaller more frequent releases it would have been done
bit-by-bit and not taken a lot of time to do all in one go.
>
> I worry a lot about making the development process more complex. The reason
> that I was fixing poms for 0.3 is that one or two people didn't
> understand the pom construction, also there were a few licences to fix.
> Without these issues (which are completely avoidable
> by putting comments in the poms and running rat in the build) it would
> really be quite fast to release the whole of Aries.
Take application 0.2.1 as an example - that happened very quickly.
What takes the time is the 72 hours for the vote but that's not 72
hours of working time, just elapsed time. Also, the need for 3 PMC
members to vote (and hence have checked the release) - well if it's
small it'll be quicker to check.
>
> Making the development process complex will make it harder to remember - and
> will likely make releasing harder because people won't remember
> the development process and the release manager will then have to fix it.
> Also, if it's so hard for us to think of what the process should be, isn't
> that an indication that we are heading for something too complex?
>
> Zoe
>
>
>
>> On Tue, Feb 1, 2011 at 16:22, Jeremy Hughes<hu...@apache.org> wrote:
>>>
>>> On 1 February 2011 14:54, Guillaume Nodet<gn...@gmail.com> wrote:
>>>>
>>>> This is very different from what we have I think, as gogo's root pom
>>>> isn't used at all.
>>>> Releasing gogo involves releasing each of the maven subproject
>>>> independantly afaik.
>>>>
>>>> The main difference is that all felix releases consists of a *single*
>>>> bundle. If we go this way, that would mean that releasing blueprint
>>>> only would require 13 releases. Some of those just contain tests, so
>>>> that does not make sense to me. From an usability point of view, I
>>>> would definitely not go that way. I'd personaly rather go in the
>>>> opposite direction and use a single reactor / release for all
>>>> components.
>>>>
>>>> Another consideration is that I think we should tie the release cycle
>>>> with the svn layout, i.e. if we want to keep each component with a
>>>> separate lifecycle, we should have multiple trunks. That's way
>>>> cleaner imho (and much more git friendly btw).
>>>
>>> Lets discuss the multiple trunks idea a bit ... are you suggesting
>>> something like:
>>>
>>> aries/application/branches
>>> aries/application/tags
>>> aries/application/trunk
>>> aries/blueprint/branches
>>> aries/blueprint/tags
>>> aries/blueprint/trunk
>>> etc
>>>
>>> We'd still be left with the multiproject issue - release blueprint
>>> 0.3.1 for a single fix and all the blueprint bundles are released
>>> whether they contain fixes or not. If each child of
>>> aries/blueprint/trunk was only a single bundle (they are today, but
>>> other top level modules like application would need some changes to
>>> fit with this) ... then we could release each of them independently.
>>>
>>> But ... every time we release a bundle in blueprint we need to release
>>> the 'uber' bundle - built from blueprint/blueprint-bundle. So, for
>>> example, we would get to a situation where we release a fix to
>>> blueprint-core @ 0.3.1 (and hence uber blueprint 0.3.1). Then
>>> blueprint-cm needs a fix release - it's next micro number would be
>>> 0.3.1 (we'd have to release uber blueprint @ 0.3.2).
>>>
>>> If blueprint-api then needs to release some additions to an interface,
>>> then according to semantic versioning rules, it has broken
>>> implementors of the interface, so its minor number goes up (to 0.4)
>>> and of course blueprint-core implementing that would need to go up to
>>> 0.4, and the uber blueprint bundle would go up to 0.4 too - but other
>>> blueprint bundles wouldn't get released and hence stay at 0.3.
>>>
>>> This is a fairly complex process that we'd need to be careful to get
>>> right.
>>>
>>>> On Tue, Feb 1, 2011 at 15:25, zoe slattery<zo...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi Felix
>>>>>
>>>>> I had a look at felix to see if I could work out how you do the
>>>>> independent
>>>>> releases. I didn't look through absolutely everything but
>>>>> I only found two modules that had sub-modules (gogo and http). Of those
>>>>> two
>>>>> it looks as though the pom structure in gogo might be similar
>>>>> to what we need in Aries. Is this a model you would recommend? Or is
>>>>> there
>>>>> something closer?
>>>>>
>>>>> Zoe
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
>>>>>>>
>>>>>>> Wouldn't that imply that each bundle has its own lifecycle ?
>>>>>>> I think a while ago we agreed on having one release per "component",
>>>>>>> i.e. blueprint (which includes api + core + cm + ...).
>>>>>>> I'm not sure how well this would go if we have blueprint-core
>>>>>>> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
>>>>>>
>>>>>> I bet you won't release blueprint-api as version 0.4.0 if it is the
>>>>>> same
>>>>>> as 0.3.0, right ?
>>>>>>
>>>>>> Regards
>>>>>> Felix
>>>>>>
>>>>>>>> From a users point of view, it certainly does not help because all
>>>>>>>> the
>>>>>>>
>>>>>>> maven transitive dependencies are kinda screwed.
>>>>>>>
>>>>>>> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<fm...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
>>>>>>>>>>>
>>>>>>>>>>> (c) Where an Aries module depends on other Aries modules, it will
>>>>>>>>>>> depend
>>>>>>>>>>> on the released versions of the other modules _until_ it requires
>>>>>>>>>>> a
>>>>>>>>>>> change in the module that it depends on, at which stage it will
>>>>>>>>>>> switch
>>>>>>>>>>> to a dependency on the development version.
>>>>>>>>>>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce
>>>>>>>>>>> 0.3,
>>>>>>>>>>> proxy
>>>>>>>>>>> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT
>>>>>>>>>>> needs
>>>>>>>>>>> to
>>>>>>>>>>> pick up a change in proxy the blueprint top level pom will need
>>>>>>>>>>> to be
>>>>>>>>>>> modified to point to proxy 0.4-SNAPSHOT.
>>>>>>>>>>
>>>>>>>>>> I would assume this means "depends on modified API" and does not
>>>>>>>>>> mean
>>>>>>>>>> "depends on some bug fixed in the implementation", right ?
>>>>>>>>>
>>>>>>>>> If you're referring to the semantic meaning attached to moving from
>>>>>>>>> 0.3 to 0.4 then I think that would be taking this discussion in a
>>>>>>>>> different direction. But that is a good point. Before getting into
>>>>>>>>> a
>>>>>>>>> semantic versioning discussion, I think the intent of this was to
>>>>>>>>> so
>>>>>>>>> if there are broken tests in 0.4-SNAPSHOT of a module which are
>>>>>>>>> fixed
>>>>>>>>> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
>>>>>>>>> should be updated.
>>>>>>>>
>>>>>>>> No, this is not about semantic versioning (yet).
>>>>>>>>
>>>>>>>> This is about the following: Consider bundle X depends on the API
>>>>>>>> org.apache.aries.y.api of bundle Y. Now some implementation of this
>>>>>>>> API
>>>>>>>> in package org.apache.aries.y.impl of bundle Y has a bug which must
>>>>>>>> be
>>>>>>>> fixed. In this case the dependency of bundle X on Y should not be
>>>>>>>> changed.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Felix
>>>>>>>>
>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Felix
>>>>>>>>>>
>>>>>>>>>>> This will lead us towards being able to release by module but it
>>>>>>>>>>> implies
>>>>>>>>>>> a change in development practice. I will make the pom changes
>>>>>>>>>>> locally
>>>>>>>>>>> and test them but I'd like to check that release-by-module is
>>>>>>>>>>> still
>>>>>>>>>>> the
>>>>>>>>>>> goal and that you all think this is a reasonable way to be able
>>>>>>>>>>> to
>>>>>>>>>>> achieve it.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Zoė
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>
>>
>
>
Re: Release by module - changes to trunk
Posted by Graham Charters <gc...@gmail.com>.
I think we need a process that "...delivers a set of pluggable Java
components enabling an enterprise OSGi application programming model",
which is what we say Aries is all about. I think we have to start
with the assumption that the process must not compromise our use of
OSGi. In other words, each bundle we produce must be independently
semantically versionable (bundle version, package versions and package
import version ranges) following the OSGi semantic versioning best
practices. With that assumption in mind, we need to work out how to
do releases in a way that's as simple as possible.
Whilst Geronimo and Karaf are probably the main consumers of Aries, I
am aware of others consuming subsets, e.g. Blueprint, JMX. I like the
idea of having a place to find all the latest Aries bundles that have
been tested together, and we should preserve that, but that doesn't
necessarily mean they all have to be released in one go. I also like
the idea of having a plugin that helps us validate semantic versions
as part of the release process. We could also do something to help
determine which dependencies also need releasing.
Thanks, Zoe, for blazing the trail in a branch. I look forward to
hearing what you find, and hopefully with the insights you'll get, we
can come up with something that satisfies all our needs. No pressure
;)
On 2 February 2011 10:56, Guillaume Nodet <gn...@gmail.com> wrote:
> I do think the releases should be as easy as possible.
>
> Having each component with a different lifecycle is not an easy
> solution imho.
> Let's take a recent example. In december, I asked for Karaf a release
> of blueprint, which ended up one months and a half later by releasing
> the whole 0.3.0 because there were lots of dependencies between
> various components.
>
> The problem is that having multiple release cycles only work:
> * if the component are really not too tied together
> * if people really use those components individually
>
> I don't think Aries components are independant enough, there are lots
> of dependencies between those and maybe I'm wrong but I think most
> users use a bunch of those components together and not only a single
> one.
>
> That means that when we'll prepare a new release of Karaf or Geronimo,
> we'll need the latest versions of everything, which I fear will lead
> to a few big releases every few months and not individual releases of
> components as you plan.
> I think this model works great for maven plugins or felix because the
> components are usually not used by the same people and are completly
> independant.
>
> FWIW, we experimented that for ServiceMix JBI components and moved to
> one release cycle per JBI component. We ended up reverting to a
> single release because we had never any need for an individual
> release.
>
> On the release process, even if it does not take days, when you
> release five components, you need to release the first one, then
> update the pom of the second one and release it aso...
> You end up wasting time imho, whereas a single "release:prepare
> release:perform" should work from the root pom imho.
>
> All the semantic versioning information should be done where it belong
> to, at the package level and we could even have some automatic checks
> put in place to verify that if an api package has changed, the version
> change is semantically correct.
>
> I think the main question to ask is: who / when / why we'll we release
> individual components? It seems the drivers so far have been Karaf
> and Geronimo and I don't recall anyone else asking for releases. So
> we need to take that into acount and switching to more fine grained
> releases if nobody asks for those will be extra work for nothing.
>
> Just my 2 cents.
>
> On Tue, Feb 1, 2011 at 18:37, zoe slattery <zo...@gmail.com> wrote:
>> On 01/02/2011 17:03, Guillaume Nodet wrote:
>>>
>>> As I said in my previous mail, one possibility would be to split the
>>> release cycle and artifact versioning scheme from the osgi package
>>> versioning scheme.
>>> Which we already do to some degree when we release blueprint-bundle
>>> which contain the blueprint-api in version 1.0 and the implementation
>>> in version 0.3.
>>>
>> I think this is worth looking into.
>>>
>>> Honestly, given the hassle of releasing things, I think a single trunk
>>> + single release cycle is the easiest way to go. I think if we have
>>> a simple release process, we could release things more often and maybe
>>> maintain branches. I don't really see any problem in having
>>> blueprint-cm-0.4.0 being the same as blueprint-cm-0.4.1. But if it
>>> takes 2 days to one person to do a release, less people will volunteer
>>> to do those, which is imho worse, as we won't deliver fixes to our
>>> users.
>>
>> The release process as it stands is actually very simple - and - though I
>> should probably not say it myself - it is well documented.
>> It took me a little time to do 0.3 but I had/chose to make fixes to a lot of
>> poms.
>>
>> I worry a lot about making the development process more complex. The reason
>> that I was fixing poms for 0.3 is that one or two people didn't
>> understand the pom construction, also there were a few licences to fix.
>> Without these issues (which are completely avoidable
>> by putting comments in the poms and running rat in the build) it would
>> really be quite fast to release the whole of Aries.
>>
>> Making the development process complex will make it harder to remember - and
>> will likely make releasing harder because people won't remember
>> the development process and the release manager will then have to fix it.
>> Also, if it's so hard for us to think of what the process should be, isn't
>> that an indication that we are heading for something too complex?
>>
>> Zoe
>>
>>
>>
>>> On Tue, Feb 1, 2011 at 16:22, Jeremy Hughes<hu...@apache.org> wrote:
>>>>
>>>> On 1 February 2011 14:54, Guillaume Nodet<gn...@gmail.com> wrote:
>>>>>
>>>>> This is very different from what we have I think, as gogo's root pom
>>>>> isn't used at all.
>>>>> Releasing gogo involves releasing each of the maven subproject
>>>>> independantly afaik.
>>>>>
>>>>> The main difference is that all felix releases consists of a *single*
>>>>> bundle. If we go this way, that would mean that releasing blueprint
>>>>> only would require 13 releases. Some of those just contain tests, so
>>>>> that does not make sense to me. From an usability point of view, I
>>>>> would definitely not go that way. I'd personaly rather go in the
>>>>> opposite direction and use a single reactor / release for all
>>>>> components.
>>>>>
>>>>> Another consideration is that I think we should tie the release cycle
>>>>> with the svn layout, i.e. if we want to keep each component with a
>>>>> separate lifecycle, we should have multiple trunks. That's way
>>>>> cleaner imho (and much more git friendly btw).
>>>>
>>>> Lets discuss the multiple trunks idea a bit ... are you suggesting
>>>> something like:
>>>>
>>>> aries/application/branches
>>>> aries/application/tags
>>>> aries/application/trunk
>>>> aries/blueprint/branches
>>>> aries/blueprint/tags
>>>> aries/blueprint/trunk
>>>> etc
>>>>
>>>> We'd still be left with the multiproject issue - release blueprint
>>>> 0.3.1 for a single fix and all the blueprint bundles are released
>>>> whether they contain fixes or not. If each child of
>>>> aries/blueprint/trunk was only a single bundle (they are today, but
>>>> other top level modules like application would need some changes to
>>>> fit with this) ... then we could release each of them independently.
>>>>
>>>> But ... every time we release a bundle in blueprint we need to release
>>>> the 'uber' bundle - built from blueprint/blueprint-bundle. So, for
>>>> example, we would get to a situation where we release a fix to
>>>> blueprint-core @ 0.3.1 (and hence uber blueprint 0.3.1). Then
>>>> blueprint-cm needs a fix release - it's next micro number would be
>>>> 0.3.1 (we'd have to release uber blueprint @ 0.3.2).
>>>>
>>>> If blueprint-api then needs to release some additions to an interface,
>>>> then according to semantic versioning rules, it has broken
>>>> implementors of the interface, so its minor number goes up (to 0.4)
>>>> and of course blueprint-core implementing that would need to go up to
>>>> 0.4, and the uber blueprint bundle would go up to 0.4 too - but other
>>>> blueprint bundles wouldn't get released and hence stay at 0.3.
>>>>
>>>> This is a fairly complex process that we'd need to be careful to get
>>>> right.
>>>>
>>>>> On Tue, Feb 1, 2011 at 15:25, zoe slattery<zo...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi Felix
>>>>>>
>>>>>> I had a look at felix to see if I could work out how you do the
>>>>>> independent
>>>>>> releases. I didn't look through absolutely everything but
>>>>>> I only found two modules that had sub-modules (gogo and http). Of those
>>>>>> two
>>>>>> it looks as though the pom structure in gogo might be similar
>>>>>> to what we need in Aries. Is this a model you would recommend? Or is
>>>>>> there
>>>>>> something closer?
>>>>>>
>>>>>> Zoe
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
>>>>>>>>
>>>>>>>> Wouldn't that imply that each bundle has its own lifecycle ?
>>>>>>>> I think a while ago we agreed on having one release per "component",
>>>>>>>> i.e. blueprint (which includes api + core + cm + ...).
>>>>>>>> I'm not sure how well this would go if we have blueprint-core
>>>>>>>> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
>>>>>>>
>>>>>>> I bet you won't release blueprint-api as version 0.4.0 if it is the
>>>>>>> same
>>>>>>> as 0.3.0, right ?
>>>>>>>
>>>>>>> Regards
>>>>>>> Felix
>>>>>>>
>>>>>>>>> From a users point of view, it certainly does not help because all
>>>>>>>>> the
>>>>>>>>
>>>>>>>> maven transitive dependencies are kinda screwed.
>>>>>>>>
>>>>>>>> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<fm...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
>>>>>>>>>>>>
>>>>>>>>>>>> (c) Where an Aries module depends on other Aries modules, it will
>>>>>>>>>>>> depend
>>>>>>>>>>>> on the released versions of the other modules _until_ it requires
>>>>>>>>>>>> a
>>>>>>>>>>>> change in the module that it depends on, at which stage it will
>>>>>>>>>>>> switch
>>>>>>>>>>>> to a dependency on the development version.
>>>>>>>>>>>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce
>>>>>>>>>>>> 0.3,
>>>>>>>>>>>> proxy
>>>>>>>>>>>> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT
>>>>>>>>>>>> needs
>>>>>>>>>>>> to
>>>>>>>>>>>> pick up a change in proxy the blueprint top level pom will need
>>>>>>>>>>>> to be
>>>>>>>>>>>> modified to point to proxy 0.4-SNAPSHOT.
>>>>>>>>>>>
>>>>>>>>>>> I would assume this means "depends on modified API" and does not
>>>>>>>>>>> mean
>>>>>>>>>>> "depends on some bug fixed in the implementation", right ?
>>>>>>>>>>
>>>>>>>>>> If you're referring to the semantic meaning attached to moving from
>>>>>>>>>> 0.3 to 0.4 then I think that would be taking this discussion in a
>>>>>>>>>> different direction. But that is a good point. Before getting into
>>>>>>>>>> a
>>>>>>>>>> semantic versioning discussion, I think the intent of this was to
>>>>>>>>>> so
>>>>>>>>>> if there are broken tests in 0.4-SNAPSHOT of a module which are
>>>>>>>>>> fixed
>>>>>>>>>> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
>>>>>>>>>> should be updated.
>>>>>>>>>
>>>>>>>>> No, this is not about semantic versioning (yet).
>>>>>>>>>
>>>>>>>>> This is about the following: Consider bundle X depends on the API
>>>>>>>>> org.apache.aries.y.api of bundle Y. Now some implementation of this
>>>>>>>>> API
>>>>>>>>> in package org.apache.aries.y.impl of bundle Y has a bug which must
>>>>>>>>> be
>>>>>>>>> fixed. In this case the dependency of bundle X on Y should not be
>>>>>>>>> changed.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Felix
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Felix
>>>>>>>>>>>
>>>>>>>>>>>> This will lead us towards being able to release by module but it
>>>>>>>>>>>> implies
>>>>>>>>>>>> a change in development practice. I will make the pom changes
>>>>>>>>>>>> locally
>>>>>>>>>>>> and test them but I'd like to check that release-by-module is
>>>>>>>>>>>> still
>>>>>>>>>>>> the
>>>>>>>>>>>> goal and that you all think this is a reasonable way to be able
>>>>>>>>>>>> to
>>>>>>>>>>>> achieve it.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Zoė
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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: Release by module - changes to trunk
Posted by Guillaume Nodet <gn...@gmail.com>.
I do think the releases should be as easy as possible.
Having each component with a different lifecycle is not an easy
solution imho.
Let's take a recent example. In december, I asked for Karaf a release
of blueprint, which ended up one months and a half later by releasing
the whole 0.3.0 because there were lots of dependencies between
various components.
The problem is that having multiple release cycles only work:
* if the component are really not too tied together
* if people really use those components individually
I don't think Aries components are independant enough, there are lots
of dependencies between those and maybe I'm wrong but I think most
users use a bunch of those components together and not only a single
one.
That means that when we'll prepare a new release of Karaf or Geronimo,
we'll need the latest versions of everything, which I fear will lead
to a few big releases every few months and not individual releases of
components as you plan.
I think this model works great for maven plugins or felix because the
components are usually not used by the same people and are completly
independant.
FWIW, we experimented that for ServiceMix JBI components and moved to
one release cycle per JBI component. We ended up reverting to a
single release because we had never any need for an individual
release.
On the release process, even if it does not take days, when you
release five components, you need to release the first one, then
update the pom of the second one and release it aso...
You end up wasting time imho, whereas a single "release:prepare
release:perform" should work from the root pom imho.
All the semantic versioning information should be done where it belong
to, at the package level and we could even have some automatic checks
put in place to verify that if an api package has changed, the version
change is semantically correct.
I think the main question to ask is: who / when / why we'll we release
individual components? It seems the drivers so far have been Karaf
and Geronimo and I don't recall anyone else asking for releases. So
we need to take that into acount and switching to more fine grained
releases if nobody asks for those will be extra work for nothing.
Just my 2 cents.
On Tue, Feb 1, 2011 at 18:37, zoe slattery <zo...@gmail.com> wrote:
> On 01/02/2011 17:03, Guillaume Nodet wrote:
>>
>> As I said in my previous mail, one possibility would be to split the
>> release cycle and artifact versioning scheme from the osgi package
>> versioning scheme.
>> Which we already do to some degree when we release blueprint-bundle
>> which contain the blueprint-api in version 1.0 and the implementation
>> in version 0.3.
>>
> I think this is worth looking into.
>>
>> Honestly, given the hassle of releasing things, I think a single trunk
>> + single release cycle is the easiest way to go. I think if we have
>> a simple release process, we could release things more often and maybe
>> maintain branches. I don't really see any problem in having
>> blueprint-cm-0.4.0 being the same as blueprint-cm-0.4.1. But if it
>> takes 2 days to one person to do a release, less people will volunteer
>> to do those, which is imho worse, as we won't deliver fixes to our
>> users.
>
> The release process as it stands is actually very simple - and - though I
> should probably not say it myself - it is well documented.
> It took me a little time to do 0.3 but I had/chose to make fixes to a lot of
> poms.
>
> I worry a lot about making the development process more complex. The reason
> that I was fixing poms for 0.3 is that one or two people didn't
> understand the pom construction, also there were a few licences to fix.
> Without these issues (which are completely avoidable
> by putting comments in the poms and running rat in the build) it would
> really be quite fast to release the whole of Aries.
>
> Making the development process complex will make it harder to remember - and
> will likely make releasing harder because people won't remember
> the development process and the release manager will then have to fix it.
> Also, if it's so hard for us to think of what the process should be, isn't
> that an indication that we are heading for something too complex?
>
> Zoe
>
>
>
>> On Tue, Feb 1, 2011 at 16:22, Jeremy Hughes<hu...@apache.org> wrote:
>>>
>>> On 1 February 2011 14:54, Guillaume Nodet<gn...@gmail.com> wrote:
>>>>
>>>> This is very different from what we have I think, as gogo's root pom
>>>> isn't used at all.
>>>> Releasing gogo involves releasing each of the maven subproject
>>>> independantly afaik.
>>>>
>>>> The main difference is that all felix releases consists of a *single*
>>>> bundle. If we go this way, that would mean that releasing blueprint
>>>> only would require 13 releases. Some of those just contain tests, so
>>>> that does not make sense to me. From an usability point of view, I
>>>> would definitely not go that way. I'd personaly rather go in the
>>>> opposite direction and use a single reactor / release for all
>>>> components.
>>>>
>>>> Another consideration is that I think we should tie the release cycle
>>>> with the svn layout, i.e. if we want to keep each component with a
>>>> separate lifecycle, we should have multiple trunks. That's way
>>>> cleaner imho (and much more git friendly btw).
>>>
>>> Lets discuss the multiple trunks idea a bit ... are you suggesting
>>> something like:
>>>
>>> aries/application/branches
>>> aries/application/tags
>>> aries/application/trunk
>>> aries/blueprint/branches
>>> aries/blueprint/tags
>>> aries/blueprint/trunk
>>> etc
>>>
>>> We'd still be left with the multiproject issue - release blueprint
>>> 0.3.1 for a single fix and all the blueprint bundles are released
>>> whether they contain fixes or not. If each child of
>>> aries/blueprint/trunk was only a single bundle (they are today, but
>>> other top level modules like application would need some changes to
>>> fit with this) ... then we could release each of them independently.
>>>
>>> But ... every time we release a bundle in blueprint we need to release
>>> the 'uber' bundle - built from blueprint/blueprint-bundle. So, for
>>> example, we would get to a situation where we release a fix to
>>> blueprint-core @ 0.3.1 (and hence uber blueprint 0.3.1). Then
>>> blueprint-cm needs a fix release - it's next micro number would be
>>> 0.3.1 (we'd have to release uber blueprint @ 0.3.2).
>>>
>>> If blueprint-api then needs to release some additions to an interface,
>>> then according to semantic versioning rules, it has broken
>>> implementors of the interface, so its minor number goes up (to 0.4)
>>> and of course blueprint-core implementing that would need to go up to
>>> 0.4, and the uber blueprint bundle would go up to 0.4 too - but other
>>> blueprint bundles wouldn't get released and hence stay at 0.3.
>>>
>>> This is a fairly complex process that we'd need to be careful to get
>>> right.
>>>
>>>> On Tue, Feb 1, 2011 at 15:25, zoe slattery<zo...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi Felix
>>>>>
>>>>> I had a look at felix to see if I could work out how you do the
>>>>> independent
>>>>> releases. I didn't look through absolutely everything but
>>>>> I only found two modules that had sub-modules (gogo and http). Of those
>>>>> two
>>>>> it looks as though the pom structure in gogo might be similar
>>>>> to what we need in Aries. Is this a model you would recommend? Or is
>>>>> there
>>>>> something closer?
>>>>>
>>>>> Zoe
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
>>>>>>>
>>>>>>> Wouldn't that imply that each bundle has its own lifecycle ?
>>>>>>> I think a while ago we agreed on having one release per "component",
>>>>>>> i.e. blueprint (which includes api + core + cm + ...).
>>>>>>> I'm not sure how well this would go if we have blueprint-core
>>>>>>> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
>>>>>>
>>>>>> I bet you won't release blueprint-api as version 0.4.0 if it is the
>>>>>> same
>>>>>> as 0.3.0, right ?
>>>>>>
>>>>>> Regards
>>>>>> Felix
>>>>>>
>>>>>>>> From a users point of view, it certainly does not help because all
>>>>>>>> the
>>>>>>>
>>>>>>> maven transitive dependencies are kinda screwed.
>>>>>>>
>>>>>>> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<fm...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
>>>>>>>>>>>
>>>>>>>>>>> (c) Where an Aries module depends on other Aries modules, it will
>>>>>>>>>>> depend
>>>>>>>>>>> on the released versions of the other modules _until_ it requires
>>>>>>>>>>> a
>>>>>>>>>>> change in the module that it depends on, at which stage it will
>>>>>>>>>>> switch
>>>>>>>>>>> to a dependency on the development version.
>>>>>>>>>>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce
>>>>>>>>>>> 0.3,
>>>>>>>>>>> proxy
>>>>>>>>>>> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT
>>>>>>>>>>> needs
>>>>>>>>>>> to
>>>>>>>>>>> pick up a change in proxy the blueprint top level pom will need
>>>>>>>>>>> to be
>>>>>>>>>>> modified to point to proxy 0.4-SNAPSHOT.
>>>>>>>>>>
>>>>>>>>>> I would assume this means "depends on modified API" and does not
>>>>>>>>>> mean
>>>>>>>>>> "depends on some bug fixed in the implementation", right ?
>>>>>>>>>
>>>>>>>>> If you're referring to the semantic meaning attached to moving from
>>>>>>>>> 0.3 to 0.4 then I think that would be taking this discussion in a
>>>>>>>>> different direction. But that is a good point. Before getting into
>>>>>>>>> a
>>>>>>>>> semantic versioning discussion, I think the intent of this was to
>>>>>>>>> so
>>>>>>>>> if there are broken tests in 0.4-SNAPSHOT of a module which are
>>>>>>>>> fixed
>>>>>>>>> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
>>>>>>>>> should be updated.
>>>>>>>>
>>>>>>>> No, this is not about semantic versioning (yet).
>>>>>>>>
>>>>>>>> This is about the following: Consider bundle X depends on the API
>>>>>>>> org.apache.aries.y.api of bundle Y. Now some implementation of this
>>>>>>>> API
>>>>>>>> in package org.apache.aries.y.impl of bundle Y has a bug which must
>>>>>>>> be
>>>>>>>> fixed. In this case the dependency of bundle X on Y should not be
>>>>>>>> changed.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Felix
>>>>>>>>
>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Felix
>>>>>>>>>>
>>>>>>>>>>> This will lead us towards being able to release by module but it
>>>>>>>>>>> implies
>>>>>>>>>>> a change in development practice. I will make the pom changes
>>>>>>>>>>> locally
>>>>>>>>>>> and test them but I'd like to check that release-by-module is
>>>>>>>>>>> still
>>>>>>>>>>> the
>>>>>>>>>>> goal and that you all think this is a reasonable way to be able
>>>>>>>>>>> to
>>>>>>>>>>> achieve it.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Zoė
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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: Release by module - changes to trunk
Posted by zoe slattery <zo...@gmail.com>.
On 01/02/2011 17:03, Guillaume Nodet wrote:
> As I said in my previous mail, one possibility would be to split the
> release cycle and artifact versioning scheme from the osgi package
> versioning scheme.
> Which we already do to some degree when we release blueprint-bundle
> which contain the blueprint-api in version 1.0 and the implementation
> in version 0.3.
>
I think this is worth looking into.
> Honestly, given the hassle of releasing things, I think a single trunk
> + single release cycle is the easiest way to go. I think if we have
> a simple release process, we could release things more often and maybe
> maintain branches. I don't really see any problem in having
> blueprint-cm-0.4.0 being the same as blueprint-cm-0.4.1. But if it
> takes 2 days to one person to do a release, less people will volunteer
> to do those, which is imho worse, as we won't deliver fixes to our
> users.
The release process as it stands is actually very simple - and - though
I should probably not say it myself - it is well documented.
It took me a little time to do 0.3 but I had/chose to make fixes to a
lot of poms.
I worry a lot about making the development process more complex. The
reason that I was fixing poms for 0.3 is that one or two people didn't
understand the pom construction, also there were a few licences to fix.
Without these issues (which are completely avoidable
by putting comments in the poms and running rat in the build) it would
really be quite fast to release the whole of Aries.
Making the development process complex will make it harder to remember -
and will likely make releasing harder because people won't remember
the development process and the release manager will then have to fix
it. Also, if it's so hard for us to think of what the process should
be, isn't that an indication that we are heading for something too complex?
Zoe
> On Tue, Feb 1, 2011 at 16:22, Jeremy Hughes<hu...@apache.org> wrote:
>> On 1 February 2011 14:54, Guillaume Nodet<gn...@gmail.com> wrote:
>>> This is very different from what we have I think, as gogo's root pom
>>> isn't used at all.
>>> Releasing gogo involves releasing each of the maven subproject
>>> independantly afaik.
>>>
>>> The main difference is that all felix releases consists of a *single*
>>> bundle. If we go this way, that would mean that releasing blueprint
>>> only would require 13 releases. Some of those just contain tests, so
>>> that does not make sense to me. From an usability point of view, I
>>> would definitely not go that way. I'd personaly rather go in the
>>> opposite direction and use a single reactor / release for all
>>> components.
>>>
>>> Another consideration is that I think we should tie the release cycle
>>> with the svn layout, i.e. if we want to keep each component with a
>>> separate lifecycle, we should have multiple trunks. That's way
>>> cleaner imho (and much more git friendly btw).
>> Lets discuss the multiple trunks idea a bit ... are you suggesting
>> something like:
>>
>> aries/application/branches
>> aries/application/tags
>> aries/application/trunk
>> aries/blueprint/branches
>> aries/blueprint/tags
>> aries/blueprint/trunk
>> etc
>>
>> We'd still be left with the multiproject issue - release blueprint
>> 0.3.1 for a single fix and all the blueprint bundles are released
>> whether they contain fixes or not. If each child of
>> aries/blueprint/trunk was only a single bundle (they are today, but
>> other top level modules like application would need some changes to
>> fit with this) ... then we could release each of them independently.
>>
>> But ... every time we release a bundle in blueprint we need to release
>> the 'uber' bundle - built from blueprint/blueprint-bundle. So, for
>> example, we would get to a situation where we release a fix to
>> blueprint-core @ 0.3.1 (and hence uber blueprint 0.3.1). Then
>> blueprint-cm needs a fix release - it's next micro number would be
>> 0.3.1 (we'd have to release uber blueprint @ 0.3.2).
>>
>> If blueprint-api then needs to release some additions to an interface,
>> then according to semantic versioning rules, it has broken
>> implementors of the interface, so its minor number goes up (to 0.4)
>> and of course blueprint-core implementing that would need to go up to
>> 0.4, and the uber blueprint bundle would go up to 0.4 too - but other
>> blueprint bundles wouldn't get released and hence stay at 0.3.
>>
>> This is a fairly complex process that we'd need to be careful to get right.
>>
>>> On Tue, Feb 1, 2011 at 15:25, zoe slattery<zo...@gmail.com> wrote:
>>>> Hi Felix
>>>>
>>>> I had a look at felix to see if I could work out how you do the independent
>>>> releases. I didn't look through absolutely everything but
>>>> I only found two modules that had sub-modules (gogo and http). Of those two
>>>> it looks as though the pom structure in gogo might be similar
>>>> to what we need in Aries. Is this a model you would recommend? Or is there
>>>> something closer?
>>>>
>>>> Zoe
>>>>> Hi,
>>>>>
>>>>> Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
>>>>>> Wouldn't that imply that each bundle has its own lifecycle ?
>>>>>> I think a while ago we agreed on having one release per "component",
>>>>>> i.e. blueprint (which includes api + core + cm + ...).
>>>>>> I'm not sure how well this would go if we have blueprint-core
>>>>>> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
>>>>> I bet you won't release blueprint-api as version 0.4.0 if it is the same
>>>>> as 0.3.0, right ?
>>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>>>> From a users point of view, it certainly does not help because all the
>>>>>> maven transitive dependencies are kinda screwed.
>>>>>>
>>>>>> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<fm...@gmail.com>
>>>>>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
>>>>>>>>>> (c) Where an Aries module depends on other Aries modules, it will
>>>>>>>>>> depend
>>>>>>>>>> on the released versions of the other modules _until_ it requires a
>>>>>>>>>> change in the module that it depends on, at which stage it will
>>>>>>>>>> switch
>>>>>>>>>> to a dependency on the development version.
>>>>>>>>>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3,
>>>>>>>>>> proxy
>>>>>>>>>> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs
>>>>>>>>>> to
>>>>>>>>>> pick up a change in proxy the blueprint top level pom will need to be
>>>>>>>>>> modified to point to proxy 0.4-SNAPSHOT.
>>>>>>>>> I would assume this means "depends on modified API" and does not mean
>>>>>>>>> "depends on some bug fixed in the implementation", right ?
>>>>>>>> If you're referring to the semantic meaning attached to moving from
>>>>>>>> 0.3 to 0.4 then I think that would be taking this discussion in a
>>>>>>>> different direction. But that is a good point. Before getting into a
>>>>>>>> semantic versioning discussion, I think the intent of this was to so
>>>>>>>> if there are broken tests in 0.4-SNAPSHOT of a module which are fixed
>>>>>>>> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
>>>>>>>> should be updated.
>>>>>>> No, this is not about semantic versioning (yet).
>>>>>>>
>>>>>>> This is about the following: Consider bundle X depends on the API
>>>>>>> org.apache.aries.y.api of bundle Y. Now some implementation of this API
>>>>>>> in package org.apache.aries.y.impl of bundle Y has a bug which must be
>>>>>>> fixed. In this case the dependency of bundle X on Y should not be
>>>>>>> changed.
>>>>>>>
>>>>>>> Regards
>>>>>>> Felix
>>>>>>>
>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Felix
>>>>>>>>>
>>>>>>>>>> This will lead us towards being able to release by module but it
>>>>>>>>>> implies
>>>>>>>>>> a change in development practice. I will make the pom changes locally
>>>>>>>>>> and test them but I'd like to check that release-by-module is still
>>>>>>>>>> the
>>>>>>>>>> goal and that you all think this is a reasonable way to be able to
>>>>>>>>>> achieve it.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Zoë
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>
>
Re: Release by module - changes to trunk
Posted by Jeremy Hughes <hu...@apache.org>.
On 1 February 2011 17:03, Guillaume Nodet <gn...@gmail.com> wrote:
> As I said in my previous mail, one possibility would be to split the
> release cycle and artifact versioning scheme from the osgi package
> versioning scheme.
> Which we already do to some degree when we release blueprint-bundle
> which contain the blueprint-api in version 1.0 and the implementation
> in version 0.3.
I agree, for semantic versioning reasons we should only change the
version packages are exported at when the package contains changes.
The bundle version will change whenever one of the packages it exports
has changed its version (major - breaking api change, minor - breaking
api for implentors, or micro - fix as was done with blueprint apis) or
the bundle includes a fix when the bundle micro number will increment.
>
> Honestly, given the hassle of releasing things, I think a single trunk
> + single release cycle is the easiest way to go. I think if we have
> a simple release process, we could release things more often and maybe
> maintain branches. I don't really see any problem in having
> blueprint-cm-0.4.0 being the same as blueprint-cm-0.4.1. But if it
> takes 2 days to one person to do a release, less people will volunteer
> to do those, which is imho worse, as we won't deliver fixes to our
> users.
The time between starting to prepare a release and starting the vote
thread shouldn't take two days particularly if it's just one module
(or even bundle if that's possible) - especially if we do it often and
therefore get a lot of practice. (IMHO)
>
> On Tue, Feb 1, 2011 at 16:22, Jeremy Hughes <hu...@apache.org> wrote:
>> On 1 February 2011 14:54, Guillaume Nodet <gn...@gmail.com> wrote:
>>> This is very different from what we have I think, as gogo's root pom
>>> isn't used at all.
>>> Releasing gogo involves releasing each of the maven subproject
>>> independantly afaik.
>>>
>>> The main difference is that all felix releases consists of a *single*
>>> bundle. If we go this way, that would mean that releasing blueprint
>>> only would require 13 releases. Some of those just contain tests, so
>>> that does not make sense to me. From an usability point of view, I
>>> would definitely not go that way. I'd personaly rather go in the
>>> opposite direction and use a single reactor / release for all
>>> components.
>>>
>>> Another consideration is that I think we should tie the release cycle
>>> with the svn layout, i.e. if we want to keep each component with a
>>> separate lifecycle, we should have multiple trunks. That's way
>>> cleaner imho (and much more git friendly btw).
>>
>> Lets discuss the multiple trunks idea a bit ... are you suggesting
>> something like:
>>
>> aries/application/branches
>> aries/application/tags
>> aries/application/trunk
>> aries/blueprint/branches
>> aries/blueprint/tags
>> aries/blueprint/trunk
>> etc
>>
>> We'd still be left with the multiproject issue - release blueprint
>> 0.3.1 for a single fix and all the blueprint bundles are released
>> whether they contain fixes or not. If each child of
>> aries/blueprint/trunk was only a single bundle (they are today, but
>> other top level modules like application would need some changes to
>> fit with this) ... then we could release each of them independently.
>>
>> But ... every time we release a bundle in blueprint we need to release
>> the 'uber' bundle - built from blueprint/blueprint-bundle. So, for
>> example, we would get to a situation where we release a fix to
>> blueprint-core @ 0.3.1 (and hence uber blueprint 0.3.1). Then
>> blueprint-cm needs a fix release - it's next micro number would be
>> 0.3.1 (we'd have to release uber blueprint @ 0.3.2).
>>
>> If blueprint-api then needs to release some additions to an interface,
>> then according to semantic versioning rules, it has broken
>> implementors of the interface, so its minor number goes up (to 0.4)
>> and of course blueprint-core implementing that would need to go up to
>> 0.4, and the uber blueprint bundle would go up to 0.4 too - but other
>> blueprint bundles wouldn't get released and hence stay at 0.3.
>>
>> This is a fairly complex process that we'd need to be careful to get right.
>>
>>>
>>> On Tue, Feb 1, 2011 at 15:25, zoe slattery <zo...@gmail.com> wrote:
>>>> Hi Felix
>>>>
>>>> I had a look at felix to see if I could work out how you do the independent
>>>> releases. I didn't look through absolutely everything but
>>>> I only found two modules that had sub-modules (gogo and http). Of those two
>>>> it looks as though the pom structure in gogo might be similar
>>>> to what we need in Aries. Is this a model you would recommend? Or is there
>>>> something closer?
>>>>
>>>> Zoe
>>>>>
>>>>> Hi,
>>>>>
>>>>> Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
>>>>>>
>>>>>> Wouldn't that imply that each bundle has its own lifecycle ?
>>>>>> I think a while ago we agreed on having one release per "component",
>>>>>> i.e. blueprint (which includes api + core + cm + ...).
>>>>>> I'm not sure how well this would go if we have blueprint-core
>>>>>> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
>>>>>
>>>>> I bet you won't release blueprint-api as version 0.4.0 if it is the same
>>>>> as 0.3.0, right ?
>>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>>> > From a users point of view, it certainly does not help because all the
>>>>>> maven transitive dependencies are kinda screwed.
>>>>>>
>>>>>> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<fm...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
>>>>>>>>>>
>>>>>>>>>> (c) Where an Aries module depends on other Aries modules, it will
>>>>>>>>>> depend
>>>>>>>>>> on the released versions of the other modules _until_ it requires a
>>>>>>>>>> change in the module that it depends on, at which stage it will
>>>>>>>>>> switch
>>>>>>>>>> to a dependency on the development version.
>>>>>>>>>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3,
>>>>>>>>>> proxy
>>>>>>>>>> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs
>>>>>>>>>> to
>>>>>>>>>> pick up a change in proxy the blueprint top level pom will need to be
>>>>>>>>>> modified to point to proxy 0.4-SNAPSHOT.
>>>>>>>>>
>>>>>>>>> I would assume this means "depends on modified API" and does not mean
>>>>>>>>> "depends on some bug fixed in the implementation", right ?
>>>>>>>>
>>>>>>>> If you're referring to the semantic meaning attached to moving from
>>>>>>>> 0.3 to 0.4 then I think that would be taking this discussion in a
>>>>>>>> different direction. But that is a good point. Before getting into a
>>>>>>>> semantic versioning discussion, I think the intent of this was to so
>>>>>>>> if there are broken tests in 0.4-SNAPSHOT of a module which are fixed
>>>>>>>> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
>>>>>>>> should be updated.
>>>>>>>
>>>>>>> No, this is not about semantic versioning (yet).
>>>>>>>
>>>>>>> This is about the following: Consider bundle X depends on the API
>>>>>>> org.apache.aries.y.api of bundle Y. Now some implementation of this API
>>>>>>> in package org.apache.aries.y.impl of bundle Y has a bug which must be
>>>>>>> fixed. In this case the dependency of bundle X on Y should not be
>>>>>>> changed.
>>>>>>>
>>>>>>> Regards
>>>>>>> Felix
>>>>>>>
>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Felix
>>>>>>>>>
>>>>>>>>>> This will lead us towards being able to release by module but it
>>>>>>>>>> implies
>>>>>>>>>> a change in development practice. I will make the pom changes locally
>>>>>>>>>> and test them but I'd like to check that release-by-module is still
>>>>>>>>>> the
>>>>>>>>>> goal and that you all think this is a reasonable way to be able to
>>>>>>>>>> achieve it.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Zoë
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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: Release by module - changes to trunk
Posted by Guillaume Nodet <gn...@gmail.com>.
As I said in my previous mail, one possibility would be to split the
release cycle and artifact versioning scheme from the osgi package
versioning scheme.
Which we already do to some degree when we release blueprint-bundle
which contain the blueprint-api in version 1.0 and the implementation
in version 0.3.
Honestly, given the hassle of releasing things, I think a single trunk
+ single release cycle is the easiest way to go. I think if we have
a simple release process, we could release things more often and maybe
maintain branches. I don't really see any problem in having
blueprint-cm-0.4.0 being the same as blueprint-cm-0.4.1. But if it
takes 2 days to one person to do a release, less people will volunteer
to do those, which is imho worse, as we won't deliver fixes to our
users.
On Tue, Feb 1, 2011 at 16:22, Jeremy Hughes <hu...@apache.org> wrote:
> On 1 February 2011 14:54, Guillaume Nodet <gn...@gmail.com> wrote:
>> This is very different from what we have I think, as gogo's root pom
>> isn't used at all.
>> Releasing gogo involves releasing each of the maven subproject
>> independantly afaik.
>>
>> The main difference is that all felix releases consists of a *single*
>> bundle. If we go this way, that would mean that releasing blueprint
>> only would require 13 releases. Some of those just contain tests, so
>> that does not make sense to me. From an usability point of view, I
>> would definitely not go that way. I'd personaly rather go in the
>> opposite direction and use a single reactor / release for all
>> components.
>>
>> Another consideration is that I think we should tie the release cycle
>> with the svn layout, i.e. if we want to keep each component with a
>> separate lifecycle, we should have multiple trunks. That's way
>> cleaner imho (and much more git friendly btw).
>
> Lets discuss the multiple trunks idea a bit ... are you suggesting
> something like:
>
> aries/application/branches
> aries/application/tags
> aries/application/trunk
> aries/blueprint/branches
> aries/blueprint/tags
> aries/blueprint/trunk
> etc
>
> We'd still be left with the multiproject issue - release blueprint
> 0.3.1 for a single fix and all the blueprint bundles are released
> whether they contain fixes or not. If each child of
> aries/blueprint/trunk was only a single bundle (they are today, but
> other top level modules like application would need some changes to
> fit with this) ... then we could release each of them independently.
>
> But ... every time we release a bundle in blueprint we need to release
> the 'uber' bundle - built from blueprint/blueprint-bundle. So, for
> example, we would get to a situation where we release a fix to
> blueprint-core @ 0.3.1 (and hence uber blueprint 0.3.1). Then
> blueprint-cm needs a fix release - it's next micro number would be
> 0.3.1 (we'd have to release uber blueprint @ 0.3.2).
>
> If blueprint-api then needs to release some additions to an interface,
> then according to semantic versioning rules, it has broken
> implementors of the interface, so its minor number goes up (to 0.4)
> and of course blueprint-core implementing that would need to go up to
> 0.4, and the uber blueprint bundle would go up to 0.4 too - but other
> blueprint bundles wouldn't get released and hence stay at 0.3.
>
> This is a fairly complex process that we'd need to be careful to get right.
>
>>
>> On Tue, Feb 1, 2011 at 15:25, zoe slattery <zo...@gmail.com> wrote:
>>> Hi Felix
>>>
>>> I had a look at felix to see if I could work out how you do the independent
>>> releases. I didn't look through absolutely everything but
>>> I only found two modules that had sub-modules (gogo and http). Of those two
>>> it looks as though the pom structure in gogo might be similar
>>> to what we need in Aries. Is this a model you would recommend? Or is there
>>> something closer?
>>>
>>> Zoe
>>>>
>>>> Hi,
>>>>
>>>> Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
>>>>>
>>>>> Wouldn't that imply that each bundle has its own lifecycle ?
>>>>> I think a while ago we agreed on having one release per "component",
>>>>> i.e. blueprint (which includes api + core + cm + ...).
>>>>> I'm not sure how well this would go if we have blueprint-core
>>>>> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
>>>>
>>>> I bet you won't release blueprint-api as version 0.4.0 if it is the same
>>>> as 0.3.0, right ?
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>>> > From a users point of view, it certainly does not help because all the
>>>>> maven transitive dependencies are kinda screwed.
>>>>>
>>>>> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<fm...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
>>>>>>>>>
>>>>>>>>> (c) Where an Aries module depends on other Aries modules, it will
>>>>>>>>> depend
>>>>>>>>> on the released versions of the other modules _until_ it requires a
>>>>>>>>> change in the module that it depends on, at which stage it will
>>>>>>>>> switch
>>>>>>>>> to a dependency on the development version.
>>>>>>>>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3,
>>>>>>>>> proxy
>>>>>>>>> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs
>>>>>>>>> to
>>>>>>>>> pick up a change in proxy the blueprint top level pom will need to be
>>>>>>>>> modified to point to proxy 0.4-SNAPSHOT.
>>>>>>>>
>>>>>>>> I would assume this means "depends on modified API" and does not mean
>>>>>>>> "depends on some bug fixed in the implementation", right ?
>>>>>>>
>>>>>>> If you're referring to the semantic meaning attached to moving from
>>>>>>> 0.3 to 0.4 then I think that would be taking this discussion in a
>>>>>>> different direction. But that is a good point. Before getting into a
>>>>>>> semantic versioning discussion, I think the intent of this was to so
>>>>>>> if there are broken tests in 0.4-SNAPSHOT of a module which are fixed
>>>>>>> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
>>>>>>> should be updated.
>>>>>>
>>>>>> No, this is not about semantic versioning (yet).
>>>>>>
>>>>>> This is about the following: Consider bundle X depends on the API
>>>>>> org.apache.aries.y.api of bundle Y. Now some implementation of this API
>>>>>> in package org.apache.aries.y.impl of bundle Y has a bug which must be
>>>>>> fixed. In this case the dependency of bundle X on Y should not be
>>>>>> changed.
>>>>>>
>>>>>> Regards
>>>>>> Felix
>>>>>>
>>>>>>
>>>>>>>> Regards
>>>>>>>> Felix
>>>>>>>>
>>>>>>>>> This will lead us towards being able to release by module but it
>>>>>>>>> implies
>>>>>>>>> a change in development practice. I will make the pom changes locally
>>>>>>>>> and test them but I'd like to check that release-by-module is still
>>>>>>>>> the
>>>>>>>>> goal and that you all think this is a reasonable way to be able to
>>>>>>>>> achieve it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Zoë
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> --
>> 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: Release by module - changes to trunk
Posted by Jeremy Hughes <hu...@apache.org>.
On 1 February 2011 14:54, Guillaume Nodet <gn...@gmail.com> wrote:
> This is very different from what we have I think, as gogo's root pom
> isn't used at all.
> Releasing gogo involves releasing each of the maven subproject
> independantly afaik.
>
> The main difference is that all felix releases consists of a *single*
> bundle. If we go this way, that would mean that releasing blueprint
> only would require 13 releases. Some of those just contain tests, so
> that does not make sense to me. From an usability point of view, I
> would definitely not go that way. I'd personaly rather go in the
> opposite direction and use a single reactor / release for all
> components.
>
> Another consideration is that I think we should tie the release cycle
> with the svn layout, i.e. if we want to keep each component with a
> separate lifecycle, we should have multiple trunks. That's way
> cleaner imho (and much more git friendly btw).
Lets discuss the multiple trunks idea a bit ... are you suggesting
something like:
aries/application/branches
aries/application/tags
aries/application/trunk
aries/blueprint/branches
aries/blueprint/tags
aries/blueprint/trunk
etc
We'd still be left with the multiproject issue - release blueprint
0.3.1 for a single fix and all the blueprint bundles are released
whether they contain fixes or not. If each child of
aries/blueprint/trunk was only a single bundle (they are today, but
other top level modules like application would need some changes to
fit with this) ... then we could release each of them independently.
But ... every time we release a bundle in blueprint we need to release
the 'uber' bundle - built from blueprint/blueprint-bundle. So, for
example, we would get to a situation where we release a fix to
blueprint-core @ 0.3.1 (and hence uber blueprint 0.3.1). Then
blueprint-cm needs a fix release - it's next micro number would be
0.3.1 (we'd have to release uber blueprint @ 0.3.2).
If blueprint-api then needs to release some additions to an interface,
then according to semantic versioning rules, it has broken
implementors of the interface, so its minor number goes up (to 0.4)
and of course blueprint-core implementing that would need to go up to
0.4, and the uber blueprint bundle would go up to 0.4 too - but other
blueprint bundles wouldn't get released and hence stay at 0.3.
This is a fairly complex process that we'd need to be careful to get right.
>
> On Tue, Feb 1, 2011 at 15:25, zoe slattery <zo...@gmail.com> wrote:
>> Hi Felix
>>
>> I had a look at felix to see if I could work out how you do the independent
>> releases. I didn't look through absolutely everything but
>> I only found two modules that had sub-modules (gogo and http). Of those two
>> it looks as though the pom structure in gogo might be similar
>> to what we need in Aries. Is this a model you would recommend? Or is there
>> something closer?
>>
>> Zoe
>>>
>>> Hi,
>>>
>>> Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
>>>>
>>>> Wouldn't that imply that each bundle has its own lifecycle ?
>>>> I think a while ago we agreed on having one release per "component",
>>>> i.e. blueprint (which includes api + core + cm + ...).
>>>> I'm not sure how well this would go if we have blueprint-core
>>>> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
>>>
>>> I bet you won't release blueprint-api as version 0.4.0 if it is the same
>>> as 0.3.0, right ?
>>>
>>> Regards
>>> Felix
>>>
>>>> > From a users point of view, it certainly does not help because all the
>>>> maven transitive dependencies are kinda screwed.
>>>>
>>>> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<fm...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
>>>>>>>>
>>>>>>>> (c) Where an Aries module depends on other Aries modules, it will
>>>>>>>> depend
>>>>>>>> on the released versions of the other modules _until_ it requires a
>>>>>>>> change in the module that it depends on, at which stage it will
>>>>>>>> switch
>>>>>>>> to a dependency on the development version.
>>>>>>>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3,
>>>>>>>> proxy
>>>>>>>> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs
>>>>>>>> to
>>>>>>>> pick up a change in proxy the blueprint top level pom will need to be
>>>>>>>> modified to point to proxy 0.4-SNAPSHOT.
>>>>>>>
>>>>>>> I would assume this means "depends on modified API" and does not mean
>>>>>>> "depends on some bug fixed in the implementation", right ?
>>>>>>
>>>>>> If you're referring to the semantic meaning attached to moving from
>>>>>> 0.3 to 0.4 then I think that would be taking this discussion in a
>>>>>> different direction. But that is a good point. Before getting into a
>>>>>> semantic versioning discussion, I think the intent of this was to so
>>>>>> if there are broken tests in 0.4-SNAPSHOT of a module which are fixed
>>>>>> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
>>>>>> should be updated.
>>>>>
>>>>> No, this is not about semantic versioning (yet).
>>>>>
>>>>> This is about the following: Consider bundle X depends on the API
>>>>> org.apache.aries.y.api of bundle Y. Now some implementation of this API
>>>>> in package org.apache.aries.y.impl of bundle Y has a bug which must be
>>>>> fixed. In this case the dependency of bundle X on Y should not be
>>>>> changed.
>>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>>
>>>>>>> Regards
>>>>>>> Felix
>>>>>>>
>>>>>>>> This will lead us towards being able to release by module but it
>>>>>>>> implies
>>>>>>>> a change in development practice. I will make the pom changes locally
>>>>>>>> and test them but I'd like to check that release-by-module is still
>>>>>>>> the
>>>>>>>> goal and that you all think this is a reasonable way to be able to
>>>>>>>> achieve it.
>>>>>>>>
>>>>>>>>
>>>>>>>> Zoë
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Release by module - changes to trunk
Posted by Guillaume Nodet <gn...@gmail.com>.
On Tue, Feb 1, 2011 at 16:17, zoe slattery <zo...@gmail.com> wrote:
> On 01/02/2011 14:54, Guillaume Nodet wrote:
>>
>> This is very different from what we have I think, as gogo's root pom
>> isn't used at all.
>> Releasing gogo involves releasing each of the maven subproject
>> independantly afaik.
>
> That might be true - I'm struggling with the logic at the moment. Wondering
> why the development version of the gogo
> runtime is 0.9.0-SNAPSHOT and the latest release seems to be 0.4.0 If there
> were released independently wouldn't the next
> development version be either 0.5.0-SNAPSHOT or 0.4.1-SNAPSHOT depending on
> the nature of the change? Oh well - probably not
> something to worry about.
You should not look at the root gogo pom as it's not used at all afaik.
The scheme has changed after 0.4.0, so newer releases are available at:
http://repo2.maven.org/maven2/org/apache/felix/org.apache.felix.gogo.runtime/
>>
>> The main difference is that all felix releases consists of a *single*
>> bundle.
>
> Yes - that was my conclusion too.
>>
>> If we go this way, that would mean that releasing blueprint
>> only would require 13 releases. Some of those just contain tests, so
>> that does not make sense to me.
>
> Completely agree.
>>
>> From an usability point of view, I
>> would definitely not go that way. I'd personaly rather go in the
>> opposite direction and use a single reactor / release for all
>> components.
>
> Well - that is where we are at the moment - so it's the least effort :-)
> I think it would be good to be able to release modules independently but a
> combination
> of having sub-modules and wanting not to break semantic versioning is making
> this difficult. Although - in effect - I suppose we
> do not follow semantic versioning already.
I think we could improve the semantic versioning at the package level
without affecting the bundle release cycle if we want.
That would mean that we'd have to have a separation between the
package versioning and the artifact versioning, which imho makes more
sense, as you could do multiple releases of the same package (for
example if a bundle contains multiple packages in different versions).
>>
>> Another consideration is that I think we should tie the release cycle
>> with the svn layout, i.e. if we want to keep each component with a
>> separate lifecycle, we should have multiple trunks. That's way
>> cleaner imho (and much more git friendly btw).
>
> Do you mean that there would be a trunk for each module?
> I'm not sure that I can see what multiple trunks would be like, does anyone
> else do this? Could you explain a bit more?
One trunk for each component.
So we'd have
svn.apache.org/repos/asf/aries/parent/trunk
svn.apache.org/repos/asf/aries/blueprint/trunk
svn.apache.org/repos/asf/aries/transaction/trunk
Lots of projects do that.
It's just I'd like a clean mapping between a trunk/release/tags and a
release cycle, so if we have a single release cycle for all
components, use a single trunk. If each component has its own release
cycle, use separate trunks.
>>
>> On Tue, Feb 1, 2011 at 15:25, zoe slattery<zo...@gmail.com> wrote:
>>>
>>> Hi Felix
>>>
>>> I had a look at felix to see if I could work out how you do the
>>> independent
>>> releases. I didn't look through absolutely everything but
>>> I only found two modules that had sub-modules (gogo and http). Of those
>>> two
>>> it looks as though the pom structure in gogo might be similar
>>> to what we need in Aries. Is this a model you would recommend? Or is
>>> there
>>> something closer?
>>>
>>> Zoe
>>>>
>>>> Hi,
>>>>
>>>> Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
>>>>>
>>>>> Wouldn't that imply that each bundle has its own lifecycle ?
>>>>> I think a while ago we agreed on having one release per "component",
>>>>> i.e. blueprint (which includes api + core + cm + ...).
>>>>> I'm not sure how well this would go if we have blueprint-core
>>>>> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
>>>>
>>>> I bet you won't release blueprint-api as version 0.4.0 if it is the same
>>>> as 0.3.0, right ?
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>>>> From a users point of view, it certainly does not help because all
>>>>>> the
>>>>>
>>>>> maven transitive dependencies are kinda screwed.
>>>>>
>>>>> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<fm...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
>>>>>>>>>
>>>>>>>>> (c) Where an Aries module depends on other Aries modules, it will
>>>>>>>>> depend
>>>>>>>>> on the released versions of the other modules _until_ it requires a
>>>>>>>>> change in the module that it depends on, at which stage it will
>>>>>>>>> switch
>>>>>>>>> to a dependency on the development version.
>>>>>>>>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3,
>>>>>>>>> proxy
>>>>>>>>> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT
>>>>>>>>> needs
>>>>>>>>> to
>>>>>>>>> pick up a change in proxy the blueprint top level pom will need to
>>>>>>>>> be
>>>>>>>>> modified to point to proxy 0.4-SNAPSHOT.
>>>>>>>>
>>>>>>>> I would assume this means "depends on modified API" and does not
>>>>>>>> mean
>>>>>>>> "depends on some bug fixed in the implementation", right ?
>>>>>>>
>>>>>>> If you're referring to the semantic meaning attached to moving from
>>>>>>> 0.3 to 0.4 then I think that would be taking this discussion in a
>>>>>>> different direction. But that is a good point. Before getting into a
>>>>>>> semantic versioning discussion, I think the intent of this was to so
>>>>>>> if there are broken tests in 0.4-SNAPSHOT of a module which are fixed
>>>>>>> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
>>>>>>> should be updated.
>>>>>>
>>>>>> No, this is not about semantic versioning (yet).
>>>>>>
>>>>>> This is about the following: Consider bundle X depends on the API
>>>>>> org.apache.aries.y.api of bundle Y. Now some implementation of this
>>>>>> API
>>>>>> in package org.apache.aries.y.impl of bundle Y has a bug which must be
>>>>>> fixed. In this case the dependency of bundle X on Y should not be
>>>>>> changed.
>>>>>>
>>>>>> Regards
>>>>>> Felix
>>>>>>
>>>>>>
>>>>>>>> Regards
>>>>>>>> Felix
>>>>>>>>
>>>>>>>>> This will lead us towards being able to release by module but it
>>>>>>>>> implies
>>>>>>>>> a change in development practice. I will make the pom changes
>>>>>>>>> locally
>>>>>>>>> and test them but I'd like to check that release-by-module is still
>>>>>>>>> the
>>>>>>>>> goal and that you all think this is a reasonable way to be able to
>>>>>>>>> achieve it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Zoė
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Release by module - changes to trunk
Posted by zoe slattery <zo...@gmail.com>.
On 01/02/2011 14:54, Guillaume Nodet wrote:
> This is very different from what we have I think, as gogo's root pom
> isn't used at all.
> Releasing gogo involves releasing each of the maven subproject
> independantly afaik.
That might be true - I'm struggling with the logic at the moment.
Wondering why the development version of the gogo
runtime is 0.9.0-SNAPSHOT and the latest release seems to be 0.4.0 If
there were released independently wouldn't the next
development version be either 0.5.0-SNAPSHOT or 0.4.1-SNAPSHOT depending
on the nature of the change? Oh well - probably not
something to worry about.
> The main difference is that all felix releases consists of a *single*
> bundle.
Yes - that was my conclusion too.
> If we go this way, that would mean that releasing blueprint
> only would require 13 releases. Some of those just contain tests, so
> that does not make sense to me.
Completely agree.
> From an usability point of view, I
> would definitely not go that way. I'd personaly rather go in the
> opposite direction and use a single reactor / release for all
> components.
Well - that is where we are at the moment - so it's the least effort :-)
I think it would be good to be able to release modules independently but
a combination
of having sub-modules and wanting not to break semantic versioning is
making this difficult. Although - in effect - I suppose we
do not follow semantic versioning already.
> Another consideration is that I think we should tie the release cycle
> with the svn layout, i.e. if we want to keep each component with a
> separate lifecycle, we should have multiple trunks. That's way
> cleaner imho (and much more git friendly btw).
Do you mean that there would be a trunk for each module?
I'm not sure that I can see what multiple trunks would be like, does
anyone else do this? Could you explain a bit more?
> On Tue, Feb 1, 2011 at 15:25, zoe slattery<zo...@gmail.com> wrote:
>> Hi Felix
>>
>> I had a look at felix to see if I could work out how you do the independent
>> releases. I didn't look through absolutely everything but
>> I only found two modules that had sub-modules (gogo and http). Of those two
>> it looks as though the pom structure in gogo might be similar
>> to what we need in Aries. Is this a model you would recommend? Or is there
>> something closer?
>>
>> Zoe
>>> Hi,
>>>
>>> Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
>>>> Wouldn't that imply that each bundle has its own lifecycle ?
>>>> I think a while ago we agreed on having one release per "component",
>>>> i.e. blueprint (which includes api + core + cm + ...).
>>>> I'm not sure how well this would go if we have blueprint-core
>>>> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
>>> I bet you won't release blueprint-api as version 0.4.0 if it is the same
>>> as 0.3.0, right ?
>>>
>>> Regards
>>> Felix
>>>
>>>>> From a users point of view, it certainly does not help because all the
>>>> maven transitive dependencies are kinda screwed.
>>>>
>>>> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<fm...@gmail.com>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
>>>>>>>> (c) Where an Aries module depends on other Aries modules, it will
>>>>>>>> depend
>>>>>>>> on the released versions of the other modules _until_ it requires a
>>>>>>>> change in the module that it depends on, at which stage it will
>>>>>>>> switch
>>>>>>>> to a dependency on the development version.
>>>>>>>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3,
>>>>>>>> proxy
>>>>>>>> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs
>>>>>>>> to
>>>>>>>> pick up a change in proxy the blueprint top level pom will need to be
>>>>>>>> modified to point to proxy 0.4-SNAPSHOT.
>>>>>>> I would assume this means "depends on modified API" and does not mean
>>>>>>> "depends on some bug fixed in the implementation", right ?
>>>>>> If you're referring to the semantic meaning attached to moving from
>>>>>> 0.3 to 0.4 then I think that would be taking this discussion in a
>>>>>> different direction. But that is a good point. Before getting into a
>>>>>> semantic versioning discussion, I think the intent of this was to so
>>>>>> if there are broken tests in 0.4-SNAPSHOT of a module which are fixed
>>>>>> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
>>>>>> should be updated.
>>>>> No, this is not about semantic versioning (yet).
>>>>>
>>>>> This is about the following: Consider bundle X depends on the API
>>>>> org.apache.aries.y.api of bundle Y. Now some implementation of this API
>>>>> in package org.apache.aries.y.impl of bundle Y has a bug which must be
>>>>> fixed. In this case the dependency of bundle X on Y should not be
>>>>> changed.
>>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>>
>>>>>>> Regards
>>>>>>> Felix
>>>>>>>
>>>>>>>> This will lead us towards being able to release by module but it
>>>>>>>> implies
>>>>>>>> a change in development practice. I will make the pom changes locally
>>>>>>>> and test them but I'd like to check that release-by-module is still
>>>>>>>> the
>>>>>>>> goal and that you all think this is a reasonable way to be able to
>>>>>>>> achieve it.
>>>>>>>>
>>>>>>>>
>>>>>>>> Zoë
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>
>
Re: Release by module - changes to trunk
Posted by Guillaume Nodet <gn...@gmail.com>.
This is very different from what we have I think, as gogo's root pom
isn't used at all.
Releasing gogo involves releasing each of the maven subproject
independantly afaik.
The main difference is that all felix releases consists of a *single*
bundle. If we go this way, that would mean that releasing blueprint
only would require 13 releases. Some of those just contain tests, so
that does not make sense to me. From an usability point of view, I
would definitely not go that way. I'd personaly rather go in the
opposite direction and use a single reactor / release for all
components.
Another consideration is that I think we should tie the release cycle
with the svn layout, i.e. if we want to keep each component with a
separate lifecycle, we should have multiple trunks. That's way
cleaner imho (and much more git friendly btw).
On Tue, Feb 1, 2011 at 15:25, zoe slattery <zo...@gmail.com> wrote:
> Hi Felix
>
> I had a look at felix to see if I could work out how you do the independent
> releases. I didn't look through absolutely everything but
> I only found two modules that had sub-modules (gogo and http). Of those two
> it looks as though the pom structure in gogo might be similar
> to what we need in Aries. Is this a model you would recommend? Or is there
> something closer?
>
> Zoe
>>
>> Hi,
>>
>> Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
>>>
>>> Wouldn't that imply that each bundle has its own lifecycle ?
>>> I think a while ago we agreed on having one release per "component",
>>> i.e. blueprint (which includes api + core + cm + ...).
>>> I'm not sure how well this would go if we have blueprint-core
>>> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
>>
>> I bet you won't release blueprint-api as version 0.4.0 if it is the same
>> as 0.3.0, right ?
>>
>> Regards
>> Felix
>>
>>> > From a users point of view, it certainly does not help because all the
>>> maven transitive dependencies are kinda screwed.
>>>
>>> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<fm...@gmail.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
>>>>>>>
>>>>>>> (c) Where an Aries module depends on other Aries modules, it will
>>>>>>> depend
>>>>>>> on the released versions of the other modules _until_ it requires a
>>>>>>> change in the module that it depends on, at which stage it will
>>>>>>> switch
>>>>>>> to a dependency on the development version.
>>>>>>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3,
>>>>>>> proxy
>>>>>>> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs
>>>>>>> to
>>>>>>> pick up a change in proxy the blueprint top level pom will need to be
>>>>>>> modified to point to proxy 0.4-SNAPSHOT.
>>>>>>
>>>>>> I would assume this means "depends on modified API" and does not mean
>>>>>> "depends on some bug fixed in the implementation", right ?
>>>>>
>>>>> If you're referring to the semantic meaning attached to moving from
>>>>> 0.3 to 0.4 then I think that would be taking this discussion in a
>>>>> different direction. But that is a good point. Before getting into a
>>>>> semantic versioning discussion, I think the intent of this was to so
>>>>> if there are broken tests in 0.4-SNAPSHOT of a module which are fixed
>>>>> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
>>>>> should be updated.
>>>>
>>>> No, this is not about semantic versioning (yet).
>>>>
>>>> This is about the following: Consider bundle X depends on the API
>>>> org.apache.aries.y.api of bundle Y. Now some implementation of this API
>>>> in package org.apache.aries.y.impl of bundle Y has a bug which must be
>>>> fixed. In this case the dependency of bundle X on Y should not be
>>>> changed.
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>>
>>>>>> Regards
>>>>>> Felix
>>>>>>
>>>>>>> This will lead us towards being able to release by module but it
>>>>>>> implies
>>>>>>> a change in development practice. I will make the pom changes locally
>>>>>>> and test them but I'd like to check that release-by-module is still
>>>>>>> the
>>>>>>> goal and that you all think this is a reasonable way to be able to
>>>>>>> achieve it.
>>>>>>>
>>>>>>>
>>>>>>> Zoë
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Release by module - changes to trunk
Posted by zoe slattery <zo...@gmail.com>.
Hi Felix
I had a look at felix to see if I could work out how you do the
independent releases. I didn't look through absolutely everything but
I only found two modules that had sub-modules (gogo and http). Of those
two it looks as though the pom structure in gogo might be similar
to what we need in Aries. Is this a model you would recommend? Or is
there something closer?
Zoe
> Hi,
>
> Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
>> Wouldn't that imply that each bundle has its own lifecycle ?
>> I think a while ago we agreed on having one release per "component",
>> i.e. blueprint (which includes api + core + cm + ...).
>> I'm not sure how well this would go if we have blueprint-core
>> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
> I bet you won't release blueprint-api as version 0.4.0 if it is the same
> as 0.3.0, right ?
>
> Regards
> Felix
>
>> > From a users point of view, it certainly does not help because all the
>> maven transitive dependencies are kinda screwed.
>>
>> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<fm...@gmail.com> wrote:
>>> Hi,
>>>
>>> Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
>>>>>> (c) Where an Aries module depends on other Aries modules, it will depend
>>>>>> on the released versions of the other modules _until_ it requires a
>>>>>> change in the module that it depends on, at which stage it will switch
>>>>>> to a dependency on the development version.
>>>>>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3, proxy
>>>>>> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs to
>>>>>> pick up a change in proxy the blueprint top level pom will need to be
>>>>>> modified to point to proxy 0.4-SNAPSHOT.
>>>>> I would assume this means "depends on modified API" and does not mean
>>>>> "depends on some bug fixed in the implementation", right ?
>>>> If you're referring to the semantic meaning attached to moving from
>>>> 0.3 to 0.4 then I think that would be taking this discussion in a
>>>> different direction. But that is a good point. Before getting into a
>>>> semantic versioning discussion, I think the intent of this was to so
>>>> if there are broken tests in 0.4-SNAPSHOT of a module which are fixed
>>>> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
>>>> should be updated.
>>> No, this is not about semantic versioning (yet).
>>>
>>> This is about the following: Consider bundle X depends on the API
>>> org.apache.aries.y.api of bundle Y. Now some implementation of this API
>>> in package org.apache.aries.y.impl of bundle Y has a bug which must be
>>> fixed. In this case the dependency of bundle X on Y should not be
>>> changed.
>>>
>>> Regards
>>> Felix
>>>
>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>>> This will lead us towards being able to release by module but it implies
>>>>>> a change in development practice. I will make the pom changes locally
>>>>>> and test them but I'd like to check that release-by-module is still the
>>>>>> goal and that you all think this is a reasonable way to be able to
>>>>>> achieve it.
>>>>>>
>>>>>>
>>>>>> Zoë
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>
>
Re: Release by module - changes to trunk
Posted by Guillaume Nodet <gn...@gmail.com>.
With the curent setup, I think we would, given all bundles in a given
component are versioned the same and released in one shot (as it's a
maven multiproject).
On Mon, Jan 31, 2011 at 15:33, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
>> Wouldn't that imply that each bundle has its own lifecycle ?
>> I think a while ago we agreed on having one release per "component",
>> i.e. blueprint (which includes api + core + cm + ...).
>> I'm not sure how well this would go if we have blueprint-core
>> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
>
> I bet you won't release blueprint-api as version 0.4.0 if it is the same
> as 0.3.0, right ?
>
> Regards
> Felix
>
>> >From a users point of view, it certainly does not help because all the
>> maven transitive dependencies are kinda screwed.
>>
>> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger <fm...@gmail.com> wrote:
>> > Hi,
>> >
>> > Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
>> >> >> (c) Where an Aries module depends on other Aries modules, it will depend
>> >> >> on the released versions of the other modules _until_ it requires a
>> >> >> change in the module that it depends on, at which stage it will switch
>> >> >> to a dependency on the development version.
>> >> >> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3, proxy
>> >> >> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs to
>> >> >> pick up a change in proxy the blueprint top level pom will need to be
>> >> >> modified to point to proxy 0.4-SNAPSHOT.
>> >> >
>> >> > I would assume this means "depends on modified API" and does not mean
>> >> > "depends on some bug fixed in the implementation", right ?
>> >>
>> >> If you're referring to the semantic meaning attached to moving from
>> >> 0.3 to 0.4 then I think that would be taking this discussion in a
>> >> different direction. But that is a good point. Before getting into a
>> >> semantic versioning discussion, I think the intent of this was to so
>> >> if there are broken tests in 0.4-SNAPSHOT of a module which are fixed
>> >> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
>> >> should be updated.
>> >
>> > No, this is not about semantic versioning (yet).
>> >
>> > This is about the following: Consider bundle X depends on the API
>> > org.apache.aries.y.api of bundle Y. Now some implementation of this API
>> > in package org.apache.aries.y.impl of bundle Y has a bug which must be
>> > fixed. In this case the dependency of bundle X on Y should not be
>> > changed.
>> >
>> > Regards
>> > Felix
>> >
>> >
>> >>
>> >> >
>> >> > Regards
>> >> > Felix
>> >> >
>> >> >>
>> >> >> This will lead us towards being able to release by module but it implies
>> >> >> a change in development practice. I will make the pom changes locally
>> >> >> and test them but I'd like to check that release-by-module is still the
>> >> >> goal and that you all think this is a reasonable way to be able to
>> >> >> achieve it.
>> >> >>
>> >> >>
>> >> >> Zoë
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >
>> >
>> >
>>
>>
>>
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Release by module - changes to trunk
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
> Wouldn't that imply that each bundle has its own lifecycle ?
> I think a while ago we agreed on having one release per "component",
> i.e. blueprint (which includes api + core + cm + ...).
> I'm not sure how well this would go if we have blueprint-core
> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
I bet you won't release blueprint-api as version 0.4.0 if it is the same
as 0.3.0, right ?
Regards
Felix
> >From a users point of view, it certainly does not help because all the
> maven transitive dependencies are kinda screwed.
>
> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger <fm...@gmail.com> wrote:
> > Hi,
> >
> > Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
> >> >> (c) Where an Aries module depends on other Aries modules, it will depend
> >> >> on the released versions of the other modules _until_ it requires a
> >> >> change in the module that it depends on, at which stage it will switch
> >> >> to a dependency on the development version.
> >> >> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3, proxy
> >> >> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs to
> >> >> pick up a change in proxy the blueprint top level pom will need to be
> >> >> modified to point to proxy 0.4-SNAPSHOT.
> >> >
> >> > I would assume this means "depends on modified API" and does not mean
> >> > "depends on some bug fixed in the implementation", right ?
> >>
> >> If you're referring to the semantic meaning attached to moving from
> >> 0.3 to 0.4 then I think that would be taking this discussion in a
> >> different direction. But that is a good point. Before getting into a
> >> semantic versioning discussion, I think the intent of this was to so
> >> if there are broken tests in 0.4-SNAPSHOT of a module which are fixed
> >> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
> >> should be updated.
> >
> > No, this is not about semantic versioning (yet).
> >
> > This is about the following: Consider bundle X depends on the API
> > org.apache.aries.y.api of bundle Y. Now some implementation of this API
> > in package org.apache.aries.y.impl of bundle Y has a bug which must be
> > fixed. In this case the dependency of bundle X on Y should not be
> > changed.
> >
> > Regards
> > Felix
> >
> >
> >>
> >> >
> >> > Regards
> >> > Felix
> >> >
> >> >>
> >> >> This will lead us towards being able to release by module but it implies
> >> >> a change in development practice. I will make the pom changes locally
> >> >> and test them but I'd like to check that release-by-module is still the
> >> >> goal and that you all think this is a reasonable way to be able to
> >> >> achieve it.
> >> >>
> >> >>
> >> >> Zoë
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >
> >
> >
>
>
>
Re: Release by module - changes to trunk
Posted by Guillaume Nodet <gn...@gmail.com>.
Wouldn't that imply that each bundle has its own lifecycle ?
I think a while ago we agreed on having one release per "component",
i.e. blueprint (which includes api + core + cm + ...).
I'm not sure how well this would go if we have blueprint-core
0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
>From a users point of view, it certainly does not help because all the
maven transitive dependencies are kinda screwed.
On Mon, Jan 31, 2011 at 15:11, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
>> >> (c) Where an Aries module depends on other Aries modules, it will depend
>> >> on the released versions of the other modules _until_ it requires a
>> >> change in the module that it depends on, at which stage it will switch
>> >> to a dependency on the development version.
>> >> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3, proxy
>> >> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs to
>> >> pick up a change in proxy the blueprint top level pom will need to be
>> >> modified to point to proxy 0.4-SNAPSHOT.
>> >
>> > I would assume this means "depends on modified API" and does not mean
>> > "depends on some bug fixed in the implementation", right ?
>>
>> If you're referring to the semantic meaning attached to moving from
>> 0.3 to 0.4 then I think that would be taking this discussion in a
>> different direction. But that is a good point. Before getting into a
>> semantic versioning discussion, I think the intent of this was to so
>> if there are broken tests in 0.4-SNAPSHOT of a module which are fixed
>> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
>> should be updated.
>
> No, this is not about semantic versioning (yet).
>
> This is about the following: Consider bundle X depends on the API
> org.apache.aries.y.api of bundle Y. Now some implementation of this API
> in package org.apache.aries.y.impl of bundle Y has a bug which must be
> fixed. In this case the dependency of bundle X on Y should not be
> changed.
>
> Regards
> Felix
>
>
>>
>> >
>> > Regards
>> > Felix
>> >
>> >>
>> >> This will lead us towards being able to release by module but it implies
>> >> a change in development practice. I will make the pom changes locally
>> >> and test them but I'd like to check that release-by-module is still the
>> >> goal and that you all think this is a reasonable way to be able to
>> >> achieve it.
>> >>
>> >>
>> >> Zoë
>> >>
>> >>
>> >>
>> >
>> >
>> >
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Release by module - changes to trunk
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
> >> (c) Where an Aries module depends on other Aries modules, it will depend
> >> on the released versions of the other modules _until_ it requires a
> >> change in the module that it depends on, at which stage it will switch
> >> to a dependency on the development version.
> >> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3, proxy
> >> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs to
> >> pick up a change in proxy the blueprint top level pom will need to be
> >> modified to point to proxy 0.4-SNAPSHOT.
> >
> > I would assume this means "depends on modified API" and does not mean
> > "depends on some bug fixed in the implementation", right ?
>
> If you're referring to the semantic meaning attached to moving from
> 0.3 to 0.4 then I think that would be taking this discussion in a
> different direction. But that is a good point. Before getting into a
> semantic versioning discussion, I think the intent of this was to so
> if there are broken tests in 0.4-SNAPSHOT of a module which are fixed
> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
> should be updated.
No, this is not about semantic versioning (yet).
This is about the following: Consider bundle X depends on the API
org.apache.aries.y.api of bundle Y. Now some implementation of this API
in package org.apache.aries.y.impl of bundle Y has a bug which must be
fixed. In this case the dependency of bundle X on Y should not be
changed.
Regards
Felix
>
> >
> > Regards
> > Felix
> >
> >>
> >> This will lead us towards being able to release by module but it implies
> >> a change in development practice. I will make the pom changes locally
> >> and test them but I'd like to check that release-by-module is still the
> >> goal and that you all think this is a reasonable way to be able to
> >> achieve it.
> >>
> >>
> >> Zoë
> >>
> >>
> >>
> >
> >
> >
Re: Release by module - changes to trunk
Posted by Jeremy Hughes <hu...@apache.org>.
On 31 January 2011 13:23, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> (from the peanut galleray again ;-)
>
> Am Montag, den 31.01.2011, 11:17 +0000 schrieb zoe slattery:
>> Hi all
>>
>> Now that we have a 0.3 release I plan to change trunk so that where
>> modules depend on other Aries modules the depend on the released
>> versions and _not_ versions in trunk.
>
> Great.
>
>>
>> This will mean:
>>
>> (a) The current development version will be 0.4-SNAPSHOT
>> (b) All Aries 0.4-SNAPSHOT modules will depend on 0.3 parent.
>> (c) Where an Aries module depends on other Aries modules, it will depend
>> on the released versions of the other modules _until_ it requires a
>> change in the module that it depends on, at which stage it will switch
>> to a dependency on the development version.
>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3, proxy
>> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs to
>> pick up a change in proxy the blueprint top level pom will need to be
>> modified to point to proxy 0.4-SNAPSHOT.
>
> I would assume this means "depends on modified API" and does not mean
> "depends on some bug fixed in the implementation", right ?
If you're referring to the semantic meaning attached to moving from
0.3 to 0.4 then I think that would be taking this discussion in a
different direction. But that is a good point. Before getting into a
semantic versioning discussion, I think the intent of this was to so
if there are broken tests in 0.4-SNAPSHOT of a module which are fixed
by pulling in 0.4-SNAPSHOT of its dependency then its dependency
should be updated.
>
> Regards
> Felix
>
>>
>> This will lead us towards being able to release by module but it implies
>> a change in development practice. I will make the pom changes locally
>> and test them but I'd like to check that release-by-module is still the
>> goal and that you all think this is a reasonable way to be able to
>> achieve it.
>>
>>
>> Zoë
>>
>>
>>
>
>
>
Re: Release by module - changes to trunk
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
(from the peanut galleray again ;-)
Am Montag, den 31.01.2011, 11:17 +0000 schrieb zoe slattery:
> Hi all
>
> Now that we have a 0.3 release I plan to change trunk so that where
> modules depend on other Aries modules the depend on the released
> versions and _not_ versions in trunk.
Great.
>
> This will mean:
>
> (a) The current development version will be 0.4-SNAPSHOT
> (b) All Aries 0.4-SNAPSHOT modules will depend on 0.3 parent.
> (c) Where an Aries module depends on other Aries modules, it will depend
> on the released versions of the other modules _until_ it requires a
> change in the module that it depends on, at which stage it will switch
> to a dependency on the development version.
> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3, proxy
> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs to
> pick up a change in proxy the blueprint top level pom will need to be
> modified to point to proxy 0.4-SNAPSHOT.
I would assume this means "depends on modified API" and does not mean
"depends on some bug fixed in the implementation", right ?
Regards
Felix
>
> This will lead us towards being able to release by module but it implies
> a change in development practice. I will make the pom changes locally
> and test them but I'd like to check that release-by-module is still the
> goal and that you all think this is a reasonable way to be able to
> achieve it.
>
>
> Zoë
>
>
>
Re: Release by module - changes to trunk
Posted by Alasdair Nottingham <no...@apache.org>.
I have made changes to the parent poms since the 0.3 release, so if we
do this I would like to have an update release of the parent so we get
these updates. It'll help us generate better javadoc for future
releases.
Alasdair
On 31 January 2011 11:17, zoe slattery <zo...@gmail.com> wrote:
> Hi all
>
> Now that we have a 0.3 release I plan to change trunk so that where modules
> depend on other Aries modules the depend on the released versions and _not_
> versions in trunk.
>
> This will mean:
>
> (a) The current development version will be 0.4-SNAPSHOT
> (b) All Aries 0.4-SNAPSHOT modules will depend on 0.3 parent.
> (c) Where an Aries module depends on other Aries modules, it will depend on
> the released versions of the other modules _until_ it requires a change in
> the module that it depends on, at which stage it will switch to a dependency
> on the development version.
> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3, proxy
> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs to
> pick up a change in proxy the blueprint top level pom will need to be
> modified to point to proxy 0.4-SNAPSHOT.
>
> This will lead us towards being able to release by module but it implies a
> change in development practice. I will make the pom changes locally and test
> them but I'd like to check that release-by-module is still the goal and that
> you all think this is a reasonable way to be able to achieve it.
>
>
> Zoė
>
>
>
>
--
Alasdair Nottingham
not@apache.org