Hi,
This is one reason to have more bug fix releases like 2.5.1, 2.7.2,
2.8.1 etc
and make an effort to back port important bug fixes to as many
stable camel versions as possible.
Then I think slight api changes is more tolerable to end users.
Björn
Yes absolutely bug fix releases are key to stability and give us more
freedom to do changes in minor releases.
Until last year I was responsible for the internal camel and cxf
distributions at a germany energy company.
CXF could normally be used as is. If there were any bugs then typically
... And it's a pity to see what's going on by the camel community
today!
Regards, Babak
[1]
https://repository.apache.org/content/repositories/snapshots/org/apache/camel/camel/2.9-SNAPSHOT/
--
View this message in context:
http://camel.465427.n5.nabble.com/DISCUSS-API-stability-in-Camel-2-x
The definition of as many versions as possible must of course be decided.
But ought to be greater than 0 (zero).
Backporting and patch-releasing bug fixes are already done today by,
for instance, fusesource and yourself earlier.
To add value for their customers.
However, I think some attention on
Björn,
Yes, that is the plan, the current thinking is that n=2. That means that
we intend to actively support 2 past releases. It also means that a
given minor release will be supported for about a year. We didn't
formalize this, and it's not easy do to so, but that's the intent.
We are now
/camel/camel/2.9-SNAPSHOT/
--
View this message in context:
http://camel.465427.n5.nabble.com/DISCUSS-API-stability-in-Camel-2-x-tp4770632p4773307.html
Sent from the Camel Development mailing list archive at Nabble.com.
--
--
Christian Schneider
http://www.liquid-reality.de
Yes there are some cases where I did not create a compatibility classes.
But these should not be in the camel API. (org.apache.camel,
org.apache.camel.spi).
Of course I know that the API is not self contained and so people use
more than the API. I did it where I think the change will not affect
Wow .. you invested some time in that story below :-)
The problem is that it is not the true story.
Let´s say we are on 2.8.x. If we neeed bug fixes only then we upgrade to
a higher bug fix version. In this version there will be no functional
changes so no problems should
occur.
If we move
/camel/2.9-SNAPSHOT/
--
View this message in context:
http://camel.465427.n5.nabble.com/DISCUSS-API-stability-in-Camel-2-x-tp4770632p4773307.html
Sent from the Camel Development mailing list archive at Nabble.com.
!
Regards, Babak
[1]
https://repository.apache.org/content/repositories/snapshots/org/apache/camel/camel/2.9-SNAPSHOT/
--
View this message in context:
http://camel.465427.n5.nabble.com/DISCUSS-API-stability-in-Camel-2-x-tp4770632p4773307.html
Sent from the Camel Development mailing list archive
://repository.apache.org/content/repositories/snapshots/org/apache/camel/camel/2.9-SNAPSHOT/
--
View this message in context:
http://camel.465427.n5.nabble.com/DISCUSS-API-stability-in-Camel-2-x-tp4770632p4773307.html
Sent from the Camel Development mailing list archive at Nabble.com
Hi
I am writing this mail with a community hat as well being a very
concerned Camel team member.
The API in camel-core had a fair number of changes recently, which is
a strong concern from a community point of view.
Basically the community views Camel 2.x as an mature and well
established
Hi Claus,
I am trying to give the community a smooth transition to 3.0 by my
current changes.
Whereever possible I use a deprecated class in the old place. So someone
who changes to camel 2.9.0 should have no problems.
He will see deprecation warnings though and this is a good thing. It
Claus,
How exactly did you get to figure out what the community wants NO CHANGES in
the the API an via what process were you nominated to express that opinion?
The reality is that the API did change in every single minor release of Camel,
and my understanding is that this is an effort to
On Mon, Sep 5, 2011 at 5:16 PM, Zbarcea Hadrian hzbar...@gmail.com wrote:
Claus,
How exactly did you get to figure out what the community wants NO CHANGES
in the the API an via what process were you nominated to express that opinion?
I guess writing all caps was a way of getting attention.
Can one point to the exact changes we're talking about here?
If those are fully compatible through using deprecation, I don't see
any major problem.
However, I don't think we should introduce incompatible changes unless
really required, especially as we *are* planning to do a 3.0 some time
in the
Maybe one way to solve those problems would be to start a 3.0 branch
and experiment / allow more api changes there and keep trunk stable
for some time, then later switch when 3.0 begins to have more focus.
On Mon, Sep 5, 2011 at 17:44, Claus Ibsen claus.ib...@gmail.com wrote:
On Mon, Sep 5, 2011
Hi Guillaume,
there are several changes I did recently. The main issue perhaps is the
current issue I opened:
https://issues.apache.org/jira/browse/CAMEL-4417
This of course a very sensible area and I plan to do this very carefully
and will create a patch to discuss before I change
With deprecate changes, we'll have no issues at all, so there I do not see it
as a change at all.
/je
On Sep 5, 2011, at 9:16 AM, Zbarcea Hadrian wrote:
Claus,
How exactly did you get to figure out what the community wants NO CHANGES
in the the API an via what process were you nominated
Hi Christian,
Here is one thing, when you introducing a new change (moving the classes
around), you may updated the unit tests as well. But it could introduce
some side effect to break the old codes, which may not covered by these
unit tests.
It will take lot time for the user to fix that
On Mon, Sep 5, 2011 at 7:13 PM, Johan Edstrom seij...@gmail.com wrote:
With deprecate changes, we'll have no issues at all, so there I do not see it
as a change at all.
Its not only deprecated changes. What we have is a mix of changes:
1) classes being deleted (without any prior warnings,
On Mon, Sep 5, 2011 at 4:39 PM, Christian Schneider
ch...@die-schneider.net wrote:
Hi Claus,
I am trying to give the community a smooth transition to 3.0 by my current
changes.
Whereever possible I use a deprecated class in the old place. So someone who
changes to camel 2.9.0 should have no
On Mon, Sep 5, 2011 at 4:54 PM, Guillaume Nodet gno...@gmail.com wrote:
Maybe one way to solve those problems would be to start a 3.0 branch
and experiment / allow more api changes there and keep trunk stable
for some time, then later switch when 3.0 begins to have more focus.
+1. I honestly
23 matches
Mail list logo
