[Camel 3 discussion] Components releases

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Camel 3 discussion] Components releases

hekonsek
Hi,

Unfortunately I won't be able to join the IRC session today as I need
to hire myself as a babysitter this evening. However I would like to
discuss some subject that come up recently [1]. One on the issues
discussed during the previous IRC session was the question whether is
it possible to release components more frequently than core.

I was wondering if we could introduce additional versioning for the
components based on the Maven version qualifiers [2] starting from
Camel 3. Qualifiers are fully supported by Maven. Versions comparison
and ranges work with qualifiers as well [3]. As far as I googled
Release Plugin can handle them correctly too (as well as
submodule-only release).

The versioning of the core would stay the same. Whenever we release
core, we release all the components as well - this doesn't change as
we want to guarantee the users that we have tested all components
against the latest core. However we could change the versioning of the
components to be qualified as follows - camel-cxf-3.0.0-CR-01 (where
CR qualifier stands for "Component Release").

What camel-cxf-3.0.0-CR-03 version would state is - this is the 3rd
version of the CXF component tested against the Camel 3.0.0 core.

This approach will require us to decouple "components" module from the
core the same was as camel-extra is. To be exact components should be
dependent on the release version of camel-core instead of SNAPSHOT.
And we should perform core release separately before the components
release.

I have never worked with qualified releases so I'm not sure if this
approach won't be the release hell, but I think we could consider this
option as Maven offers qualifiers out of the box. This may be a nice
option to reduce time needed to deliver the latest artifacts to the
end users.

What do you think?

Best regards.

[1] http://camel.465427.n5.nabble.com/DISCUSS-CAMEL-3-0-weekly-IRC-chat-at-02-12-2013-7-00PM-8-00PM-CET-td5727462.html
[2] http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html
[3] http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution

--
Henryk Konsek
http://henryk-konsek.blogspot.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

Claus Ibsen-2
I am -1 on this.

On Tue, Feb 19, 2013 at 8:16 AM, Henryk Konsek <[hidden email]> wrote:

> Hi,
>
> Unfortunately I won't be able to join the IRC session today as I need
> to hire myself as a babysitter this evening. However I would like to
> discuss some subject that come up recently [1]. One on the issues
> discussed during the previous IRC session was the question whether is
> it possible to release components more frequently than core.
>
> I was wondering if we could introduce additional versioning for the
> components based on the Maven version qualifiers [2] starting from
> Camel 3. Qualifiers are fully supported by Maven. Versions comparison
> and ranges work with qualifiers as well [3]. As far as I googled
> Release Plugin can handle them correctly too (as well as
> submodule-only release).
>
> The versioning of the core would stay the same. Whenever we release
> core, we release all the components as well - this doesn't change as
> we want to guarantee the users that we have tested all components
> against the latest core. However we could change the versioning of the
> components to be qualified as follows - camel-cxf-3.0.0-CR-01 (where
> CR qualifier stands for "Component Release").
>
> What camel-cxf-3.0.0-CR-03 version would state is - this is the 3rd
> version of the CXF component tested against the Camel 3.0.0 core.
>
> This approach will require us to decouple "components" module from the
> core the same was as camel-extra is. To be exact components should be
> dependent on the release version of camel-core instead of SNAPSHOT.
> And we should perform core release separately before the components
> release.
>
> I have never worked with qualified releases so I'm not sure if this
> approach won't be the release hell, but I think we could consider this
> option as Maven offers qualifiers out of the box. This may be a nice
> option to reduce time needed to deliver the latest artifacts to the
> end users.
>
> What do you think?
>
> Best regards.
>
> [1] http://camel.465427.n5.nabble.com/DISCUSS-CAMEL-3-0-weekly-IRC-chat-at-02-12-2013-7-00PM-8-00PM-CET-td5727462.html
> [2] http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html
> [3] http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com



--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

hekonsek
> I am -1 on this.

Would you mind telling me any particular reason behind this -1? I'm
just curious why this idea is so terribly bad :) .

--
Henryk Konsek
http://henryk-konsek.blogspot.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

James Carman-2
In reply to this post by Claus Ibsen-2
A veto must be accompanied by a justification in order for it to stand:

http://www.apache.org/foundation/voting.html

On Feb 19, 2013, at 1:13 PM, Claus Ibsen <[hidden email]> wrote:

> I am -1 on this.
>
> On Tue, Feb 19, 2013 at 8:16 AM, Henryk Konsek <[hidden email]> wrote:
>> Hi,
>>
>> Unfortunately I won't be able to join the IRC session today as I need
>> to hire myself as a babysitter this evening. However I would like to
>> discuss some subject that come up recently [1]. One on the issues
>> discussed during the previous IRC session was the question whether is
>> it possible to release components more frequently than core.
>>
>> I was wondering if we could introduce additional versioning for the
>> components based on the Maven version qualifiers [2] starting from
>> Camel 3. Qualifiers are fully supported by Maven. Versions comparison
>> and ranges work with qualifiers as well [3]. As far as I googled
>> Release Plugin can handle them correctly too (as well as
>> submodule-only release).
>>
>> The versioning of the core would stay the same. Whenever we release
>> core, we release all the components as well - this doesn't change as
>> we want to guarantee the users that we have tested all components
>> against the latest core. However we could change the versioning of the
>> components to be qualified as follows - camel-cxf-3.0.0-CR-01 (where
>> CR qualifier stands for "Component Release").
>>
>> What camel-cxf-3.0.0-CR-03 version would state is - this is the 3rd
>> version of the CXF component tested against the Camel 3.0.0 core.
>>
>> This approach will require us to decouple "components" module from the
>> core the same was as camel-extra is. To be exact components should be
>> dependent on the release version of camel-core instead of SNAPSHOT.
>> And we should perform core release separately before the components
>> release.
>>
>> I have never worked with qualified releases so I'm not sure if this
>> approach won't be the release hell, but I think we could consider this
>> option as Maven offers qualifiers out of the box. This may be a nice
>> option to reduce time needed to deliver the latest artifacts to the
>> end users.
>>
>> What do you think?
>>
>> Best regards.
>>
>> [1] http://camel.465427.n5.nabble.com/DISCUSS-CAMEL-3-0-weekly-IRC-chat-at-02-12-2013-7-00PM-8-00PM-CET-td5727462.html
>> [2] http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html
>> [3] http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
>>
>> --
>> Henryk Konsek
>> http://henryk-konsek.blogspot.com
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

Raul Kripalani
In reply to this post by hekonsek
The value proposition is awesome. But it's way too complex for a community
to manage up to 130+ independent lifecycles.

On the other hand, as a user, I'd love to upgrade my Camel JMS component to
a newer release without upgrading Camel as a whole. To pull in bug fixes, a
particularly interesting feature, etc. As a prerequisite, we'd need a
completely static API throughout 3.x that components can bind to. So I
could run Camel 3.1 with camel-jms 3.2, for example.

That said, taking a wild guess, most users won't run a mix'n'match
deployment. If they use 20 components, they'll probably stick to the main
version for most of them, except for when they need a very particular bug
fix or feature in a given component. Only then will they consider upgrading
that component. SNAPSHOT and nightly builds can help, but the handicap is
that they are volatile releases. So you are never ever guaranteed to get
the same binary from Maven Central at two different times.

So my proposal is to create a "hotfix" procedure within the Camel
community. If a Committer feels they have just committed an important fix
which cannot wait for the next Camel release, they can push a hotfix
release to Maven Central, e.g. camel-jms-3.2.1-HF-01. Performing such
releases is at the full discretion of Committers, and of course, can be
demanded by the community.

WDYT? I don't know how feasible this is from the organisational viewpoint
(who can perform a release, sync with Maven Central, etc.), but it looks
like a solid solution for the real problem at hand: being able to push
important component fixes to the community quickly and nimbly.

If other committers feel similarly, we can find a way to make it work!

Regards,

*Raúl Kripalani*
Apache Camel Committer
Enterprise Architect, Program Manager, Open Source Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk>

On Tue, Feb 19, 2013 at 7:16 AM, Henryk Konsek <[hidden email]> wrote:

> Hi,
>
> Unfortunately I won't be able to join the IRC session today as I need
> to hire myself as a babysitter this evening. However I would like to
> discuss some subject that come up recently [1]. One on the issues
> discussed during the previous IRC session was the question whether is
> it possible to release components more frequently than core.
>
> I was wondering if we could introduce additional versioning for the
> components based on the Maven version qualifiers [2] starting from
> Camel 3. Qualifiers are fully supported by Maven. Versions comparison
> and ranges work with qualifiers as well [3]. As far as I googled
> Release Plugin can handle them correctly too (as well as
> submodule-only release).
>
> The versioning of the core would stay the same. Whenever we release
> core, we release all the components as well - this doesn't change as
> we want to guarantee the users that we have tested all components
> against the latest core. However we could change the versioning of the
> components to be qualified as follows - camel-cxf-3.0.0-CR-01 (where
> CR qualifier stands for "Component Release").
>
> What camel-cxf-3.0.0-CR-03 version would state is - this is the 3rd
> version of the CXF component tested against the Camel 3.0.0 core.
>
> This approach will require us to decouple "components" module from the
> core the same was as camel-extra is. To be exact components should be
> dependent on the release version of camel-core instead of SNAPSHOT.
> And we should perform core release separately before the components
> release.
>
> I have never worked with qualified releases so I'm not sure if this
> approach won't be the release hell, but I think we could consider this
> option as Maven offers qualifiers out of the box. This may be a nice
> option to reduce time needed to deliver the latest artifacts to the
> end users.
>
> What do you think?
>
> Best regards.
>
> [1]
> http://camel.465427.n5.nabble.com/DISCUSS-CAMEL-3-0-weekly-IRC-chat-at-02-12-2013-7-00PM-8-00PM-CET-td5727462.html
> [2]
> http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html
> [3]
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

Christian Schneider
In reply to this post by hekonsek
This sounds like it could be pretty difficult to manage.
How about a simpler model?

A component could specify the minimum camel core or better api in the
future it needs.
For example:

camel-jms 3.0 -> camel-core 3.0
camel-jms 3.1 -> camel-core 3.0

For OSGi dependencies this would make the package imports automatically
specify >= 3.0 < 4 for both camel-jms versions. So the newer camel-jms
version would work with the old camel-core.
So we would still release all parts of camel for all releases and still
be able to mix them more freely.

Christian


Am 19.02.2013 08:16, schrieb Henryk Konsek:

> Hi,
>
> Unfortunately I won't be able to join the IRC session today as I need
> to hire myself as a babysitter this evening. However I would like to
> discuss some subject that come up recently [1]. One on the issues
> discussed during the previous IRC session was the question whether is
> it possible to release components more frequently than core.
>
> I was wondering if we could introduce additional versioning for the
> components based on the Maven version qualifiers [2] starting from
> Camel 3. Qualifiers are fully supported by Maven. Versions comparison
> and ranges work with qualifiers as well [3]. As far as I googled
> Release Plugin can handle them correctly too (as well as
> submodule-only release).
>
> The versioning of the core would stay the same. Whenever we release
> core, we release all the components as well - this doesn't change as
> we want to guarantee the users that we have tested all components
> against the latest core. However we could change the versioning of the
> components to be qualified as follows - camel-cxf-3.0.0-CR-01 (where
> CR qualifier stands for "Component Release").
>
> What camel-cxf-3.0.0-CR-03 version would state is - this is the 3rd
> version of the CXF component tested against the Camel 3.0.0 core.
>
> This approach will require us to decouple "components" module from the
> core the same was as camel-extra is. To be exact components should be
> dependent on the release version of camel-core instead of SNAPSHOT.
> And we should perform core release separately before the components
> release.
>
> I have never worked with qualified releases so I'm not sure if this
> approach won't be the release hell, but I think we could consider this
> option as Maven offers qualifiers out of the box. This may be a nice
> option to reduce time needed to deliver the latest artifacts to the
> end users.
>
> What do you think?
>
> Best regards.
>
> [1] http://camel.465427.n5.nabble.com/DISCUSS-CAMEL-3-0-weekly-IRC-chat-at-02-12-2013-7-00PM-8-00PM-CET-td5727462.html
> [2] http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html
> [3] http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com


--
 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

hekonsek
In reply to this post by Raul Kripalani
Hi Raul,

> So my proposal is to create a "hotfix" procedure within the Camel
> community. If a Committer feels they have just committed an important fix
> which cannot wait for the next Camel release, they can push a hotfix
> release to Maven Central, e.g. camel-jms-3.2.1-HF-01.
> Performing such
> releases is at the full discretion of Committers, and of course, can be
> demanded by the community.

This is essentially what I've proposed. :)

But keep in mind that due to the Maven versioning resolution [1] we
need to append qualifier (for example -HF-01) to the first released
version of the artifact. Because for Maven camel-jms-3.2.1-HF-01 is
older than camel-jms-3.2.1. We need to be nice for Maven in this
regards because many plugins relay on the proper versioning strategy.
That's why I proposed to release components with -CR-01 qualifier
already in place.

> The value proposition is awesome. But it's way too complex for a community
> to manage up to 130+ independent lifecycles

There are no so independent as they are bounded to the borders of core
releases. The core version is the common denominator here.

> That said, taking a wild guess, most users won't run a mix'n'match
> deployment.

There is no mixing here, as component is tested and released again
certain version of core. Keep in mind that when core updates, we will
perform full release and "reset" the components qualifiers. There is
no ambiguity here - it is clear that camel-jms-3.2.1-CR-xx is supposed
to be deployed only with camel-core 3.2.1.

> SNAPSHOT and nightly builds can help, but the handicap is
> that they are volatile releases. So you are never ever guaranteed to get
> the same binary from Maven Central at two different times.

Deploying SNAPSHOTS or nightly builds to the production is asking for
trouble. That's why we (users) want independent versioning for
components.

[1] http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution

--
Henryk Konsek
http://henryk-konsek.blogspot.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

hekonsek
In reply to this post by Christian Schneider
Hi Christian,

> How about a simpler model?
> A component could specify the minimum camel core or better api in the future
> it needs.
> For example:
> camel-jms 3.0 -> camel-core 3.0
> camel-jms 3.1 -> camel-core 3.0

Unfortunately this approach doesn't address the problem that component
users still need to wait for core to be released if they want the
latest version of the component. The main issue I try to address is to
give the users faster access the to the released components without
waiting for the core release.

Best regards.

--
Henryk Konsek
http://henryk-konsek.blogspot.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

Raul Kripalani
In reply to this post by hekonsek
Hi Henry,

From what I understood, you were suggesting a different versioning model
for components at the POM level.

My suggestion was to keep the current POM versioning model, but just create
a "component hotfix" repository where we can publish "tags" of components
upon demand. To continue with my example, the version on camel-jms would
remain intact, following exactly camel-core (or the future camel-api, if
that idea prospers). We'd just run mvn release to tag and publish hotfix
releases for a component.

Concerning the Maven versioning policy, I don't like components having a
different version nomenclature than the rest of Camel. I'd much rather make
all Camel elements use "-GA" to indicate General Availability, just like
Spring do.

Regards,

*Raúl Kripalani*
Apache Camel Committer
Enterprise Architect, Program Manager, Open Source Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk>

On Tue, Feb 19, 2013 at 10:04 PM, Henryk Konsek <[hidden email]> wrote:

> Hi Raul,
>
> > So my proposal is to create a "hotfix" procedure within the Camel
> > community. If a Committer feels they have just committed an important fix
> > which cannot wait for the next Camel release, they can push a hotfix
> > release to Maven Central, e.g. camel-jms-3.2.1-HF-01.
> > Performing such
> > releases is at the full discretion of Committers, and of course, can be
> > demanded by the community.
>
> This is essentially what I've proposed. :)
>
> But keep in mind that due to the Maven versioning resolution [1] we
> need to append qualifier (for example -HF-01) to the first released
> version of the artifact. Because for Maven camel-jms-3.2.1-HF-01 is
> older than camel-jms-3.2.1. We need to be nice for Maven in this
> regards because many plugins relay on the proper versioning strategy.
> That's why I proposed to release components with -CR-01 qualifier
> already in place.
>
> > The value proposition is awesome. But it's way too complex for a
> community
> > to manage up to 130+ independent lifecycles
>
> There are no so independent as they are bounded to the borders of core
> releases. The core version is the common denominator here.
>
> > That said, taking a wild guess, most users won't run a mix'n'match
> > deployment.
>
> There is no mixing here, as component is tested and released again
> certain version of core. Keep in mind that when core updates, we will
> perform full release and "reset" the components qualifiers. There is
> no ambiguity here - it is clear that camel-jms-3.2.1-CR-xx is supposed
> to be deployed only with camel-core 3.2.1.
>
> > SNAPSHOT and nightly builds can help, but the handicap is
> > that they are volatile releases. So you are never ever guaranteed to get
> > the same binary from Maven Central at two different times.
>
> Deploying SNAPSHOTS or nightly builds to the production is asking for
> trouble. That's why we (users) want independent versioning for
> components.
>
> [1]
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

hadrian
In reply to this post by James Carman-2
Except this is not a vote and hence not a veto :).
Claus expressed that his views are different, no biggie.

Cheers,
Hadrian

On 02/19/2013 02:51 PM, James Carman wrote:

> A veto must be accompanied by a justification in order for it to stand:
>
> http://www.apache.org/foundation/voting.html
>
> On Feb 19, 2013, at 1:13 PM, Claus Ibsen <[hidden email]> wrote:
>
>> I am -1 on this.
>>
>> On Tue, Feb 19, 2013 at 8:16 AM, Henryk Konsek <[hidden email]> wrote:
>>> Hi,
>>>
>>> Unfortunately I won't be able to join the IRC session today as I need
>>> to hire myself as a babysitter this evening. However I would like to
>>> discuss some subject that come up recently [1]. One on the issues
>>> discussed during the previous IRC session was the question whether is
>>> it possible to release components more frequently than core.
>>>
>>> I was wondering if we could introduce additional versioning for the
>>> components based on the Maven version qualifiers [2] starting from
>>> Camel 3. Qualifiers are fully supported by Maven. Versions comparison
>>> and ranges work with qualifiers as well [3]. As far as I googled
>>> Release Plugin can handle them correctly too (as well as
>>> submodule-only release).
>>>
>>> The versioning of the core would stay the same. Whenever we release
>>> core, we release all the components as well - this doesn't change as
>>> we want to guarantee the users that we have tested all components
>>> against the latest core. However we could change the versioning of the
>>> components to be qualified as follows - camel-cxf-3.0.0-CR-01 (where
>>> CR qualifier stands for "Component Release").
>>>
>>> What camel-cxf-3.0.0-CR-03 version would state is - this is the 3rd
>>> version of the CXF component tested against the Camel 3.0.0 core.
>>>
>>> This approach will require us to decouple "components" module from the
>>> core the same was as camel-extra is. To be exact components should be
>>> dependent on the release version of camel-core instead of SNAPSHOT.
>>> And we should perform core release separately before the components
>>> release.
>>>
>>> I have never worked with qualified releases so I'm not sure if this
>>> approach won't be the release hell, but I think we could consider this
>>> option as Maven offers qualifiers out of the box. This may be a nice
>>> option to reduce time needed to deliver the latest artifacts to the
>>> end users.
>>>
>>> What do you think?
>>>
>>> Best regards.
>>>
>>> [1] http://camel.465427.n5.nabble.com/DISCUSS-CAMEL-3-0-weekly-IRC-chat-at-02-12-2013-7-00PM-8-00PM-CET-td5727462.html
>>> [2] http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html
>>> [3] http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
>>>
>>> --
>>> Henryk Konsek
>>> http://henryk-konsek.blogspot.com
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Email: [hidden email]
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

hadrian
In reply to this post by hekonsek
And actually the core should not even change that often. And the api
should change even less often. Ideally we would only have major api
releases (ideally, that is).

Hopefully we'll find a better solution for our release process.

Cheers,
Hadrian


On 02/19/2013 05:21 PM, Henryk Konsek wrote:

> Hi Christian,
>
>> How about a simpler model?
>> A component could specify the minimum camel core or better api in the future
>> it needs.
>> For example:
>> camel-jms 3.0 -> camel-core 3.0
>> camel-jms 3.1 -> camel-core 3.0
>
> Unfortunately this approach doesn't address the problem that component
> users still need to wait for core to be released if they want the
> latest version of the component. The main issue I try to address is to
> give the users faster access the to the released components without
> waiting for the core release.
>
> Best regards.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

Willem.Jiang
In reply to this post by hekonsek
It's hard to track all the version of camel-component and it will make the release process every complex, if we don't release it with the core. So I cannot agree with this proposal.  

As you know In ServiceMix we have lots components which have not direct dependency with the core, so we break this components out and release them separately. Before we do the servicemix release, we need to release the kernel ( which is Karaf now), bundles, components, features. Because the Apache 3 days release vote policy, a whole release will take for weeks. It holds the release for years, and we can see ServiceMix can barely do one major release per year.

In Camel we provides the patch release after the major release, I think it is not a big deal if we need to meet the needs of camel component release. BTW, the patch release is also slow down the trunk development, as it is time consuming work that we need to merge back the patch to assume it works in different branch.  

--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
          http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem





On Tuesday, February 19, 2013 at 3:16 PM, Henryk Konsek wrote:

> Hi,
>  
> Unfortunately I won't be able to join the IRC session today as I need
> to hire myself as a babysitter this evening. However I would like to
> discuss some subject that come up recently [1]. One on the issues
> discussed during the previous IRC session was the question whether is
> it possible to release components more frequently than core.
>  
> I was wondering if we could introduce additional versioning for the
> components based on the Maven version qualifiers [2] starting from
> Camel 3. Qualifiers are fully supported by Maven. Versions comparison
> and ranges work with qualifiers as well [3]. As far as I googled
> Release Plugin can handle them correctly too (as well as
> submodule-only release).
>  
> The versioning of the core would stay the same. Whenever we release
> core, we release all the components as well - this doesn't change as
> we want to guarantee the users that we have tested all components
> against the latest core. However we could change the versioning of the
> components to be qualified as follows - camel-cxf-3.0.0-CR-01 (where
> CR qualifier stands for "Component Release").
>  
> What camel-cxf-3.0.0-CR-03 version would state is - this is the 3rd
> version of the CXF component tested against the Camel 3.0.0 core.
>  
> This approach will require us to decouple "components" module from the
> core the same was as camel-extra is. To be exact components should be
> dependent on the release version of camel-core instead of SNAPSHOT.
> And we should perform core release separately before the components
> release.
>  
> I have never worked with qualified releases so I'm not sure if this
> approach won't be the release hell, but I think we could consider this
> option as Maven offers qualifiers out of the box. This may be a nice
> option to reduce time needed to deliver the latest artifacts to the
> end users.
>  
> What do you think?
>  
> Best regards.
>  
> [1] http://camel.465427.n5.nabble.com/DISCUSS-CAMEL-3-0-weekly-IRC-chat-at-02-12-2013-7-00PM-8-00PM-CET-td5727462.html
> [2] http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html
> [3] http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
>  
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

Christian Schneider
In reply to this post by hekonsek
I am -1 for separate component releases. There are two problems:

1. Each component release needs a vote. So with the 100+ components we
would have 100 votes instead of one vote for a camel release.
Of course it is less in practice as not every component is released
every time but still a lot of votes.

2. We need to support each release of a component for a certain time and
make sure it is compatible to camel core and other components in various
releases.
So a support request may read like: I am using camel-core 3.0.1 with
camel-jms 2.5.4 and camel-jetty 3.2.2 but sometimes get exception xy.
This is quite hard to support.
Compare this to people who now say I am using camel 2.2.10 with
camel-jms and camel-jetty. Even my proposal would make support a lot harder.

I think it makes sense to have minor releases every let´s say 3 months
and bugfix releases for each supported minor release also about every
1-3 months. So if we support a minor release for a year
it means we have about 4 minor releases to support in parallel.

If we would theoretically release every component every 3 months or even
faster it would mean we have a gigantic number of branches and version
combinations to support. This is not manageable in my opinion.

Christian

Am 19.02.2013 23:21, schrieb Henryk Konsek:

> Hi Christian,
>
>> How about a simpler model?
>> A component could specify the minimum camel core or better api in the future
>> it needs.
>> For example:
>> camel-jms 3.0 -> camel-core 3.0
>> camel-jms 3.1 -> camel-core 3.0
> Unfortunately this approach doesn't address the problem that component
> users still need to wait for core to be released if they want the
> latest version of the component. The main issue I try to address is to
> give the users faster access the to the released components without
> waiting for the core release.
>
> Best regards.
>


--
 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

Maruan Sahyoun
Hi,

Apache Camel is the victim of it's own success here. It's easy to build new components and people are encouraged to do so. This leads to the large amount of components available and their number will grow.

IMHO the focus should be on
o a stable, thin core.
o a good component model
o some components maintained and released together with core
o a 'component marketplace' where other components are available

E.g. is camel-fop really essential to a large audience? Should it be maintained as part of a core effort? We are willing to add to CAMEL-3552 (pdf component) but is this interesting to many? Will this be a component which needs to be released and maintained regulary? If I contribute such a component who is responsible for its further maintenance?

Maybe a look at projects like jQuery, Wordpress and many others shows how this can be done successfully.

This would help to focus on a good foundation, a basic set of components and a solid documentation and samples for how to extend these. And a community driven set of components to add. Apache Camel could provide the infrastructure for these or services like GitHub can be used maybe in a similar manner jQuery does it. "Giving" up some of the components will benefit all of us as this will free the time needed for doing core development and quicker releases if there is something needed and/or broken in core.

Kind regards and many thanks for a great software foundation.

Maruan Sahyoun



Am 20.02.2013 um 08:09 schrieb Christian Schneider <[hidden email]>:

> I am -1 for separate component releases. There are two problems:
>
> 1. Each component release needs a vote. So with the 100+ components we would have 100 votes instead of one vote for a camel release.
> Of course it is less in practice as not every component is released every time but still a lot of votes.
>
> 2. We need to support each release of a component for a certain time and make sure it is compatible to camel core and other components in various releases.
> So a support request may read like: I am using camel-core 3.0.1 with camel-jms 2.5.4 and camel-jetty 3.2.2 but sometimes get exception xy. This is quite hard to support.
> Compare this to people who now say I am using camel 2.2.10 with camel-jms and camel-jetty. Even my proposal would make support a lot harder.
>
> I think it makes sense to have minor releases every let´s say 3 months and bugfix releases for each supported minor release also about every 1-3 months. So if we support a minor release for a year
> it means we have about 4 minor releases to support in parallel.
>
> If we would theoretically release every component every 3 months or even faster it would mean we have a gigantic number of branches and version combinations to support. This is not manageable in my opinion.
>
> Christian
>
> Am 19.02.2013 23:21, schrieb Henryk Konsek:
>> Hi Christian,
>>
>>> How about a simpler model?
>>> A component could specify the minimum camel core or better api in the future
>>> it needs.
>>> For example:
>>> camel-jms 3.0 -> camel-core 3.0
>>> camel-jms 3.1 -> camel-core 3.0
>> Unfortunately this approach doesn't address the problem that component
>> users still need to wait for core to be released if they want the
>> latest version of the component. The main issue I try to address is to
>> give the users faster access the to the released components without
>> waiting for the core release.
>>
>> Best regards.
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

Christian Schneider
Hi Maruan,

I agree with the goals you defined.

A stable and thin core would be great. The problem is that core is not
really thin at the moment. So I think we need to do at least one release
with breaking changes before we can then have a stable and thin core.

The idea of a component marketplace sounds great. What we need to make
it work is a community for the components outside camel. The apache
processes are not very suitable for these separate components.
Maybe ops4j could be a choice. After choosing a community we would then
have to decide which components to keep in camel and which to move to
the marketplace. I guess this could be done with a poll by selecting the
most used and wanted components to stay in camel. Github as a place to
store the components is good but we need a community that makes sure
legal and licensing concerns are addressed. Github does not care about this.
Last but not least this community has to provide a defined way to get
these components into maven central so it is as easy as now to use them.

Christian

Am 20.02.2013 09:11, schrieb Maruan Sahyoun:

> Hi,
>
> Apache Camel is the victim of it's own success here. It's easy to build new components and people are encouraged to do so. This leads to the large amount of components available and their number will grow.
>
> IMHO the focus should be on
> o a stable, thin core.
> o a good component model
> o some components maintained and released together with core
> o a 'component marketplace' where other components are available
>
> E.g. is camel-fop really essential to a large audience? Should it be maintained as part of a core effort? We are willing to add to CAMEL-3552 (pdf component) but is this interesting to many? Will this be a component which needs to be released and maintained regulary? If I contribute such a component who is responsible for its further maintenance?
>
> Maybe a look at projects like jQuery, Wordpress and many others shows how this can be done successfully.
>
> This would help to focus on a good foundation, a basic set of components and a solid documentation and samples for how to extend these. And a community driven set of components to add. Apache Camel could provide the infrastructure for these or services like GitHub can be used maybe in a similar manner jQuery does it. "Giving" up some of the components will benefit all of us as this will free the time needed for doing core development and quicker releases if there is something needed and/or broken in core.
>
> Kind regards and many thanks for a great software foundation.
>
> Maruan Sahyoun
>
>
>
> Am 20.02.2013 um 08:09 schrieb Christian Schneider <[hidden email]>:
>
>> I am -1 for separate component releases. There are two problems:
>>
>> 1. Each component release needs a vote. So with the 100+ components we would have 100 votes instead of one vote for a camel release.
>> Of course it is less in practice as not every component is released every time but still a lot of votes.
>>
>> 2. We need to support each release of a component for a certain time and make sure it is compatible to camel core and other components in various releases.
>> So a support request may read like: I am using camel-core 3.0.1 with camel-jms 2.5.4 and camel-jetty 3.2.2 but sometimes get exception xy. This is quite hard to support.
>> Compare this to people who now say I am using camel 2.2.10 with camel-jms and camel-jetty. Even my proposal would make support a lot harder.
>>
>> I think it makes sense to have minor releases every let´s say 3 months and bugfix releases for each supported minor release also about every 1-3 months. So if we support a minor release for a year
>> it means we have about 4 minor releases to support in parallel.
>>
>> If we would theoretically release every component every 3 months or even faster it would mean we have a gigantic number of branches and version combinations to support. This is not manageable in my opinion.
>>
>> Christian
>>
>> Am 19.02.2013 23:21, schrieb Henryk Konsek:
>>> Hi Christian,
>>>
>>>> How about a simpler model?
>>>> A component could specify the minimum camel core or better api in the future
>>>> it needs.
>>>> For example:
>>>> camel-jms 3.0 -> camel-core 3.0
>>>> camel-jms 3.1 -> camel-core 3.0
>>> Unfortunately this approach doesn't address the problem that component
>>> users still need to wait for core to be released if they want the
>>> latest version of the component. The main issue I try to address is to
>>> give the users faster access the to the released components without
>>> waiting for the core release.
>>>
>>> Best regards.
>>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>


--
 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

Maruan Sahyoun
a discussion/decision how to handle components is independent of a stable and thin core. I mentioned it only to have the 'layers' complete. The points you are making are very valid and as has been proven by others they can be addressed. What I wanted to introduce is the idea of not being responsible for all components themselves. Providing the 'marketplace' and procedures associated with it on the other hand should be handled by the project. This way Apache Camel will provide the foundation from a coding as well as infrastructure/terms and procedures perspective.

I think jQuery is a good example of how that could be done http://plugins.jquery.com/ . Take a look at the submenus
        • Naming Your Plugin
        • Publishing Your Plugin
        • Package Manifest

Kind regards

Maruan Sahyoun



Am 20.02.2013 um 09:24 schrieb Christian Schneider <[hidden email]>:

> Hi Maruan,
>
> I agree with the goals you defined.
>
> A stable and thin core would be great. The problem is that core is not really thin at the moment. So I think we need to do at least one release with breaking changes before we can then have a stable and thin core.
>
> The idea of a component marketplace sounds great. What we need to make it work is a community for the components outside camel. The apache processes are not very suitable for these separate components.
> Maybe ops4j could be a choice. After choosing a community we would then have to decide which components to keep in camel and which to move to the marketplace. I guess this could be done with a poll by selecting the most used and wanted components to stay in camel. Github as a place to store the components is good but we need a community that makes sure legal and licensing concerns are addressed. Github does not care about this.
> Last but not least this community has to provide a defined way to get these components into maven central so it is as easy as now to use them.
>
> Christian
>
> Am 20.02.2013 09:11, schrieb Maruan Sahyoun:
>> Hi,
>>
>> Apache Camel is the victim of it's own success here. It's easy to build new components and people are encouraged to do so. This leads to the large amount of components available and their number will grow.
>>
>> IMHO the focus should be on
>> o a stable, thin core.
>> o a good component model
>> o some components maintained and released together with core
>> o a 'component marketplace' where other components are available
>>
>> E.g. is camel-fop really essential to a large audience? Should it be maintained as part of a core effort? We are willing to add to CAMEL-3552 (pdf component) but is this interesting to many? Will this be a component which needs to be released and maintained regulary? If I contribute such a component who is responsible for its further maintenance?
>>
>> Maybe a look at projects like jQuery, Wordpress and many others shows how this can be done successfully.
>>
>> This would help to focus on a good foundation, a basic set of components and a solid documentation and samples for how to extend these. And a community driven set of components to add. Apache Camel could provide the infrastructure for these or services like GitHub can be used maybe in a similar manner jQuery does it. "Giving" up some of the components will benefit all of us as this will free the time needed for doing core development and quicker releases if there is something needed and/or broken in core.
>>
>> Kind regards and many thanks for a great software foundation.
>>
>> Maruan Sahyoun
>>
>>
>>
>> Am 20.02.2013 um 08:09 schrieb Christian Schneider <[hidden email]>:
>>
>>> I am -1 for separate component releases. There are two problems:
>>>
>>> 1. Each component release needs a vote. So with the 100+ components we would have 100 votes instead of one vote for a camel release.
>>> Of course it is less in practice as not every component is released every time but still a lot of votes.
>>>
>>> 2. We need to support each release of a component for a certain time and make sure it is compatible to camel core and other components in various releases.
>>> So a support request may read like: I am using camel-core 3.0.1 with camel-jms 2.5.4 and camel-jetty 3.2.2 but sometimes get exception xy. This is quite hard to support.
>>> Compare this to people who now say I am using camel 2.2.10 with camel-jms and camel-jetty. Even my proposal would make support a lot harder.
>>>
>>> I think it makes sense to have minor releases every let´s say 3 months and bugfix releases for each supported minor release also about every 1-3 months. So if we support a minor release for a year
>>> it means we have about 4 minor releases to support in parallel.
>>>
>>> If we would theoretically release every component every 3 months or even faster it would mean we have a gigantic number of branches and version combinations to support. This is not manageable in my opinion.
>>>
>>> Christian
>>>
>>> Am 19.02.2013 23:21, schrieb Henryk Konsek:
>>>> Hi Christian,
>>>>
>>>>> How about a simpler model?
>>>>> A component could specify the minimum camel core or better api in the future
>>>>> it needs.
>>>>> For example:
>>>>> camel-jms 3.0 -> camel-core 3.0
>>>>> camel-jms 3.1 -> camel-core 3.0
>>>> Unfortunately this approach doesn't address the problem that component
>>>> users still need to wait for core to be released if they want the
>>>> latest version of the component. The main issue I try to address is to
>>>> give the users faster access the to the released components without
>>>> waiting for the core release.
>>>>
>>>> Best regards.
>>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

Christian Schneider
The idea of a common process and rules but separate owners for the
components sounds good. We would have to discuss / agree on the details
of course. This would then of course also imply that the camel community
would not officially support the marketplace components. So rather each
component would be supported by an individual group.

Christian

On 20.02.2013 10:04, Maruan Sahyoun wrote:

> a discussion/decision how to handle components is independent of a stable and thin core. I mentioned it only to have the 'layers' complete. The points you are making are very valid and as has been proven by others they can be addressed. What I wanted to introduce is the idea of not being responsible for all components themselves. Providing the 'marketplace' and procedures associated with it on the other hand should be handled by the project. This way Apache Camel will provide the foundation from a coding as well as infrastructure/terms and procedures perspective.
>
> I think jQuery is a good example of how that could be done http://plugins.jquery.com/ . Take a look at the submenus
> • Naming Your Plugin
> • Publishing Your Plugin
> • Package Manifest
>
> Kind regards
>
> Maruan Sahyoun
>
>

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

Maruan Sahyoun
you nailed it. The idea of the marketplace is to give up responsibility. Apache Camel is responsible for the foundation (software, infrastructure, procedures). The component developer has responsibility for the component.

Maruan Sahyoun

Am 20.02.2013 um 10:19 schrieb Christian Schneider <[hidden email]>:

> The idea of a common process and rules but separate owners for the
> components sounds good. We would have to discuss / agree on the details
> of course. This would then of course also imply that the camel community
> would not officially support the marketplace components. So rather each
> component would be supported by an individual group.
>
> Christian
>
> On 20.02.2013 10:04, Maruan Sahyoun wrote:
>> a discussion/decision how to handle components is independent of a stable and thin core. I mentioned it only to have the 'layers' complete. The points you are making are very valid and as has been proven by others they can be addressed. What I wanted to introduce is the idea of not being responsible for all components themselves. Providing the 'marketplace' and procedures associated with it on the other hand should be handled by the project. This way Apache Camel will provide the foundation from a coding as well as infrastructure/terms and procedures perspective.
>>
>> I think jQuery is a good example of how that could be done http://plugins.jquery.com/ . Take a look at the submenus
>> • Naming Your Plugin
>> • Publishing Your Plugin
>> • Package Manifest
>>
>> Kind regards
>>
>> Maruan Sahyoun
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

Raul Kripalani
Hi,

I don't think a marketplace and surrendering responsibility of components
helps solve the problem we are discussing.

We don't have an ownership/responsibility/authorship issue: it's a release
lifecycle discussion. How do we deliver component fixes to the community
quickly? Surrendering them doesn't seem to be the solution. Truth is that
we do have enough capacity in the Camel project to maintain the components
we host. As proof, most (sensible) component tickets are resolved within 1
week of their creation; some in just hours.

BTW - we usually encourage users to donate their custom components to the
Camel project, if they use ASL-compatible libraries. For the rest, there's
already a marketplace at camel-extra [1] that hosts non-ASL compatible
components.

Regards,

[1] http://code.google.com/a/apache-extras.org/p/camel-extra/

*Raúl Kripalani*
Apache Camel Committer
Enterprise Architect, Program Manager, Open Source Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk>

On Wed, Feb 20, 2013 at 9:38 AM, Maruan Sahyoun <[hidden email]>wrote:

> you nailed it. The idea of the marketplace is to give up responsibility.
> Apache Camel is responsible for the foundation (software, infrastructure,
> procedures). The component developer has responsibility for the component.
>
> Maruan Sahyoun
>
> Am 20.02.2013 um 10:19 schrieb Christian Schneider <
> [hidden email]>:
>
> > The idea of a common process and rules but separate owners for the
> > components sounds good. We would have to discuss / agree on the details
> > of course. This would then of course also imply that the camel community
> > would not officially support the marketplace components. So rather each
> > component would be supported by an individual group.
> >
> > Christian
> >
> > On 20.02.2013 10:04, Maruan Sahyoun wrote:
> >> a discussion/decision how to handle components is independent of a
> stable and thin core. I mentioned it only to have the 'layers' complete.
> The points you are making are very valid and as has been proven by others
> they can be addressed. What I wanted to introduce is the idea of not being
> responsible for all components themselves. Providing the 'marketplace' and
> procedures associated with it on the other hand should be handled by the
> project. This way Apache Camel will provide the foundation from a coding as
> well as infrastructure/terms and procedures perspective.
> >>
> >> I think jQuery is a good example of how that could be done
> http://plugins.jquery.com/ . Take a look at the submenus
> >>      • Naming Your Plugin
> >>      • Publishing Your Plugin
> >>      • Package Manifest
> >>
> >> Kind regards
> >>
> >> Maruan Sahyoun
> >>
> >>
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
> >
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Camel 3 discussion] Components releases

Maruan Sahyoun
well IMHO this would also address the release lifecycle question. That part of the discussion initiated the idea. If there are enough people around to maintain the components that's great. On the other hand are there also enough people around to move Camel 3.0 forward AND maintain all components? Bottom line from my outsiders perspective following your discussions was that there are too many things to be done within a certain period of time. I might be wrong though.

Maruan Sahyoun

Am 20.02.2013 um 11:26 schrieb Raul Kripalani <[hidden email]>:

> Hi,
>
> I don't think a marketplace and surrendering responsibility of components
> helps solve the problem we are discussing.
>
> We don't have an ownership/responsibility/authorship issue: it's a release
> lifecycle discussion. How do we deliver component fixes to the community
> quickly? Surrendering them doesn't seem to be the solution. Truth is that
> we do have enough capacity in the Camel project to maintain the components
> we host. As proof, most (sensible) component tickets are resolved within 1
> week of their creation; some in just hours.
>
> BTW - we usually encourage users to donate their custom components to the
> Camel project, if they use ASL-compatible libraries. For the rest, there's
> already a marketplace at camel-extra [1] that hosts non-ASL compatible
> components.
>
> Regards,
>
> [1] http://code.google.com/a/apache-extras.org/p/camel-extra/
>
> *Raúl Kripalani*
> Apache Camel Committer
> Enterprise Architect, Program Manager, Open Source Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk>
>
> On Wed, Feb 20, 2013 at 9:38 AM, Maruan Sahyoun <[hidden email]>wrote:
>
>> you nailed it. The idea of the marketplace is to give up responsibility.
>> Apache Camel is responsible for the foundation (software, infrastructure,
>> procedures). The component developer has responsibility for the component.
>>
>> Maruan Sahyoun
>>
>> Am 20.02.2013 um 10:19 schrieb Christian Schneider <
>> [hidden email]>:
>>
>>> The idea of a common process and rules but separate owners for the
>>> components sounds good. We would have to discuss / agree on the details
>>> of course. This would then of course also imply that the camel community
>>> would not officially support the marketplace components. So rather each
>>> component would be supported by an individual group.
>>>
>>> Christian
>>>
>>> On 20.02.2013 10:04, Maruan Sahyoun wrote:
>>>> a discussion/decision how to handle components is independent of a
>> stable and thin core. I mentioned it only to have the 'layers' complete.
>> The points you are making are very valid and as has been proven by others
>> they can be addressed. What I wanted to introduce is the idea of not being
>> responsible for all components themselves. Providing the 'marketplace' and
>> procedures associated with it on the other hand should be handled by the
>> project. This way Apache Camel will provide the foundation from a coding as
>> well as infrastructure/terms and procedures perspective.
>>>>
>>>> I think jQuery is a good example of how that could be done
>> http://plugins.jquery.com/ . Take a look at the submenus
>>>>     • Naming Your Plugin
>>>>     • Publishing Your Plugin
>>>>     • Package Manifest
>>>>
>>>> Kind regards
>>>>
>>>> Maruan Sahyoun
>>>>
>>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>
>>

12
Loading...