-1 (non-binding)
I agree with Jon and Claus here. I think there is way more downside-- we
already have trouble explaining to users that you can't mix camel-core 2.8.0
with camel-jms 2.7.1 and camel-jetty 2.12.0. IMHO, additional "meaning" behind
a version number will only further complicate th
I wouldn't imagine these separate component releases would be able to have
differing dependency versions anyway. So no win there. We would get into
the situation of having multiple versions of the same lib being used across
Camel. That is one of the nice things about releasing everything at once,
On Tue, Feb 19, 2013 at 7:56 PM, Henryk Konsek wrote:
>> 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
Hi Henryk
I am sorry I was short-sided
I really don't like the idea. If the goal is to deliver fixes to users,
why not increase the release frequency of micro releases ?
It will cause much less troubles and keep things manageable and simple for
both the devs and users communities.
On Tue, Feb 19, 2013 at 8:16 AM, Henryk Konsek wro
Good to see a very active discussion...
But is there a reason I'm not familiar with that this MUST be done in Camel
3.0? I don't think so...
I would like to add this topic to the Camel road map page [1] for Camel 3.x
(after Camel 3.0) and postpone the discussion to a time where the
development for
Over 30 messages in the thread. Now I feel like real Internet Troll [1] :P
Anyway thank you all for expressing your views in the regards of
components maintenance. It's good to see how others perceive the
future of the components in Camel. Any further input is welcome.
[1] http://en.wikipedia.org
Am 20.02.2013 um 16:22 schrieb Henryk Konsek :
>> But aren't there situations today where people might not be able to update
>> camel?
>
> These situations are minor ones comparing to the size of
> incompatibility that will be caused by introducing components not
> supported by the committers
> But aren't there situations today where people might not be able to update
> camel?
These situations are minor ones comparing to the size of
incompatibility that will be caused by introducing components not
supported by the committers team.
> No need to stop working on select components and ei
> The quality would be in the responsibility of the owner.
Code ownership doesn't play well with the quality of the open source
code. Let's face it - the components without the organized care from
the committers team will be lousy. The existing components released
from the ASF umbrella will degrad
>
>
>> Maruan:
>> 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.
>
> If we follow this path, we will end u
Isn't this whole situation similar to the Apache Web Server project and their
plugins? How do they do it?
On Feb 20, 2013, at 9:16 AM, Christian Schneider
wrote:
> Am 20.02.2013 14:26, schrieb Raul Kripalani:
>> I'm thinking about the organisation strategy here. Below is a list of a few
>>
Am 20.02.2013 14:53, schrieb Henryk Konsek:
Christian:
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.
CR-01 release of all components would be performed together with core.
Component releases higher than CR-01
hi - although I didn't think about all implications please find some comments
below.
As I'm new to Apache Camel I might not be in the position to provide all these
suggestions and ideas. If I unintentionally step on someones toes please
forgive me :-)
Maruan Sahyoun
Am 20.02.2013 um 14:26 sch
Am 20.02.2013 14:26, schrieb Raul Kripalani:
I'm thinking about the organisation strategy here. Below is a list of a few
practical issues off the top of my head. For the people supporting the the
marketplace idea, could you elaborate on how we'd handle these?
- Would marketplace components b
> Christian:
> 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.
CR-01 release of all components would be performed together with core.
Component releases higher than CR-01 would be performed seldom,
usually on ex
I'm thinking about the organisation strategy here. Below is a list of a few
practical issues off the top of my head. For the people supporting the the
marketplace idea, could you elaborate on how we'd handle these?
- Would marketplace components be sponsored/owned by committers only, or
anyo
I also think it would be a good idea to concentrate on core and a few
important components. The sheer number of components got a little out of
control recently.
So for example we could keep the 10 or 20 most important components in
camel and move the rest out to a marketplace.
Christian
Am 20
Maruan,
Actually I think you're spot on, and I shared some of these thoughts for
a good while. I believe it's just a matter of time for others to reach
the same conclusion.
My $0.02,
Hadrian
On 02/20/2013 05:37 AM, Maruan Sahyoun wrote:
well IMHO this would also address the release lifecycl
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
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 d
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 :
> T
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
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 respons
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 marketp
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 c
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
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 t
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:
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 1
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
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 sti
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
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 pac
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 f
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 wrote:
> I am -1 on this.
>
> On Tue, Feb 19, 2013 at 8:16 AM, Henryk Konsek wrote:
>> Hi,
>>
>> Unfortunately I won't be able to join
> 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
I am -1 on this.
On Tue, Feb 19, 2013 at 8:16 AM, 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
> discu
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 rele
38 matches
Mail list logo
