On Sat, Sep 24, 2011 at 10:30 PM, Christian Müller
christian.muel...@gmail.com wrote:
That's exactly what I think, Hadrian.
A minor release has not to be 100% backwarts compatiple. Of course we try
our best to be 100% backwarts compatible in minor releases, but it should
not be a problem if
On Sat, Sep 24, 2011 at 5:07 PM, Ioannis Canellos ioca...@gmail.com wrote:
I understand that there are two respectable views on the subject:
a) We should guarantee forward compatibility for 2.x as the major version
implies.
b) The API changes should not wait for the 3.0.0 release as its not
It seems to me this discussion is mostly related to how / when introduce
changes in the API.
One possible way would be:
* micro release: no api change
* minor release: 100% backward compatible api changes
* major release: incompatible changes
Now, I agree with Hiram in that @deprecated
Yes there are probably some undocumented changes. The question is though
if they would hit anyone. That is why I would like to do a release
candidate for 2.9. So
people can try to run their projects with the refactorings and we can
even react before the first official 2.9 release.
About the
Am 26.09.2011 11:04, schrieb Claus Ibsen:
See the survey we did where people comment that they want the API
stable. http://camel.apache.org/camel-30-roadmap.html (link on top of
this page) We have not recently put our a survey to ask for feedback
in the community if they want bigger API
On Mon, Sep 26, 2011 at 1:29 PM, Christian Schneider
ch...@die-schneider.net wrote:
Am 26.09.2011 11:04, schrieb Claus Ibsen:
See the survey we did where people comment that they want the API stable.
http://camel.apache.org/camel-30-roadmap.html (link on top of this page) We
have not recently
On Mon, Sep 26, 2011 at 1:17 PM, Christian Schneider
ch...@die-schneider.net wrote:
Yes there are probably some undocumented changes. The question is though if
they would hit anyone. That is why I would like to do a release candidate
for 2.9. So
people can try to run their projects with the
The question comes down to: is it worth taking the risk of breaking users
applications while this can be done safely in a major release. Those
changes are not enabler, it's just cleaner at the end. So while I think
those changes are good, they may be delayed until 3.0.
I don't really understand
I posted the basic ideas and goals of the refactorings in the Camel 3.0
roadmap and also started discussions on DEV. One of the first is:
http://camel.465427.n5.nabble.com/Some-thoughts-about-the-architecture-of-camel-td3217183.html#a3218958
The problem is that I could not already discuss the
Again, it seems to me that you're implying Claus has problems with the
changes you did.
Reading his emails, I think the problems are more related to which branch /
when do the changes rather than if we do the changes.
On Mon, Sep 26, 2011 at 14:30, Christian Schneider
On Mon, Sep 26, 2011 at 2:36 PM, Guillaume Nodet gno...@gmail.com wrote:
Again, it seems to me that you're implying Claus has problems with the
changes you did.
Reading his emails, I think the problems are more related to which branch /
when do the changes rather than if we do the changes.
Am 26.09.2011 14:02, schrieb Claus Ibsen:
On Mon, Sep 26, 2011 at 1:17 PM, Christian Schneider
ch...@die-schneider.net wrote:
Yes there are probably some undocumented changes. The question is though if
they would hit anyone. That is why I would like to do a release candidate
for 2.9. So
people
My thoughts exactly... I don't see what the big deal is waiting to introduce
these changes till 3.0. Why does it HAVE to be in 2.9? I've heard in the
past and several folks have mentioned in this thread that users have
complained when we introduced API breakages in minor releases in the past so
On Mon, Sep 26, 2011 at 2:45 PM, Christian Schneider
ch...@die-schneider.net wrote:
Am 26.09.2011 14:02, schrieb Claus Ibsen:
On Mon, Sep 26, 2011 at 1:17 PM, Christian Schneider
ch...@die-schneider.net wrote:
Yes there are probably some undocumented changes. The question is though
if
Basically you are right. The 3.0 version will definately need some RCs.
Still I think the risk of incompatibilities in 2.9 could warrant an RC
here too. (If we do 2.9 from current trunk).
So if we fix everything that people report in 2.9-RC1 the probability
that 2.9.0 will be compatible is
On Mon, Sep 26, 2011 at 8:02 AM, Claus Ibsen claus.ib...@gmail.com wrote:
On Mon, Sep 26, 2011 at 1:17 PM, Christian Schneider
ch...@die-schneider.net wrote:
About the SPI changes I propose
(https://issues.apache.org/jira/browse/CAMEL-4475). This would of course be
a breaking change for
On Monday, September 26, 2011 2:02:35 PM Claus Ibsen wrote:
On Mon, Sep 26, 2011 at 1:17 PM, Christian Schneider
ch...@die-schneider.net wrote:
Yes there are probably some undocumented changes. The question is though
if they would hit anyone. That is why I would like to do a release
Not really sure to which of the many messages to reply to, I just chose
this one. I tried to educate myself on what the issues are (obviously
more than one). Thanks to all who helped, you know who you are.
I understand that we all agree on the need to maintain backward
compatibility close to
On Mon, Sep 26, 2011 at 11:26 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:
Not really sure to which of the many messages to reply to, I just chose this
one. I tried to educate myself on what the issues are (obviously more than
one). Thanks to all who helped, you know who you are.
I
On 9/25/11 9:14 AM, Hadrian Zbarcea wrote:
Ioannis, what you suggest is similar to what Christian was suggesting
except instead of a 2.9 and maybe a 2.10 who knows, you would be ok with
calling these versions 3.0, 3.1, with the intention, probably, to
accommodate Claus' proposal.
Now, to answer
Willem, it sounds to me like you agree on most of the issues, correct?
Comments inline.
Hadrian
I think already stated my +1 for a new API module to break the cycle
dependency of camel-core which was proposed by Christian.
Excellent.
But I don't think we should ship the camel-api module
The fact that it's not 100% compatible IS why it's not a good idea to
call it 2.x. The point of version numbering schemes are to reflect
the compatibility between releases. If trunk is not a major release,
I don't know what is. And yes I would hope that the 3.x line tries to
keep as much
I don't think we're debating if, we're debating when. I get your point
and I would agree if this was any different than before. The reality
though is that *every* single minor release of Camel was *not* 100%
backwards compatible. We absolutely strive for backward compatibility
and 2.9.0 should
I understand that there are two respectable views on the subject:
a) We should guarantee forward compatibility for 2.x as the major version
implies.
b) The API changes should not wait for the 3.0.0 release as its not going to
happen any time soon.
I was wondering if it would be possible to make
That's exactly what I think, Hadrian.
A minor release has not to be 100% backwarts compatiple. Of course we try
our best to be 100% backwarts compatible in minor releases, but it should
not be a problem if we aren't, as long as we document the not backwarts
compatible changes.
A micro/bugfix
Ioannis, what you suggest is similar to what Christian was suggesting
except instead of a 2.9 and maybe a 2.10 who knows, you would be ok with
calling these versions 3.0, 3.1, with the intention, probably, to
accommodate Claus' proposal.
Now, to answer Willem and Rob other messages in this
On Sat, Sep 24, 2011 at 9:14 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:
* cleanup the api an architecture to allow one to use camel as an
integration framework *without* the routing part. For instance one should be
able to use just a producer template and the components of choice with a
Donald, you are mostly correct, this would require mostly repackaging of
the jars, i.e. splitting the core into multiple jars. We will probably
have to do something with the CamelContext, it became a bit of a
hodge-podge. In any case, the intent is for the migration to be still
simple and
Hi
I would like to propose that Camel source code currently on trunk is
to be Camel 3.0.0.
And the current code on the 2.8.x branch is to be used for the 2.x
lifetime of Camel.
The reason for this can be summarized as:
1) All the API changes on trunk, and still to be done API changes
2) Preserve
Hi Claus,
we could do this but it would mean that all the compatibility measures I
put in place are in vain.
As far as I understand it we want to remove all @Deprecated stuff in
camel 3.0. That means that people will have a quite incompatible update
if we do not prepare well for it.
So my
On Fri, Sep 23, 2011 at 1:36 PM, Christian Schneider
ch...@die-schneider.net wrote:
Hi Claus,
we could do this but it would mean that all the compatibility measures I put
in place are in vain.
Its not in vain. Because when the API in Camel 3.0 is becoming clear
to us that this is what we
-1 at this point in time.
I have this topic a lot of thought during the past months. During a
transition, *if* you want to maintain backwards compatibility as much as
possible, there will necessarily be some bloat (code dealing with both
the new and the old).
It is much better to have this
Well I don´t think that works.
If we add the @Deprecated annotation in the old code but we do not add
the new code then people can not really move their code easily.
@Deprecated only makes sense if the new and the old code are present at
the same time. This can only be done in 2.x as we want
+1
On 23 Sep 2011, at 12:13, Claus Ibsen wrote:
Hi
I would like to propose that Camel source code currently on trunk is
to be Camel 3.0.0.
And the current code on the 2.8.x branch is to be used for the 2.x
lifetime of Camel.
The reason for this can be summarized as:
1) All the API
I think the main concern of Christian is he afraid Camel 3.0 won't have
much user to use, and he explain us the recent back ports of Camel
2.8.2 is because of the API change in Camel 2.9-SNAPSHOT.
How about we treat the Camel 2.9 as the Camel 3.0-m1. When we developed
Camel 2.0, we actual
-1 - this makes no sense to me. Christian and Hadrian have done a ton of
work to make sure those changes are completely compatible for 2.x users while
also providing those users a glimpse into what 3.0 will look like and
providing migration paths for those users.That's a *good* thing.
The reality is that users, want stability and they will be unwilling to move
to versions above 2.8.x unless there's a compelling reason to do so. So if they
know a 3.0 is in the works, they will wait till that version is GA before
considering upgrading. So try to get them to transition easily
I think we can spend 6~9 month to do the Camel 3.0 mile stone release.
In this way we can provide user enough time to do the migration.
Camel 2.8.x can be our 2.x maintenance branch for a lot time :)
On 9/23/11 9:11 PM, Hadrian Zbarcea wrote:
-1 at this point in time.
I have this topic a lot
Rob, if you are labeling what I said as a red herring, please re-read
and spend some time to understand what I said. I'll come back with a
more detailed answer later if need (but I am crossing my fingers and
hope that won't be necessary).
Hadrian
On 09/23/2011 10:13 AM, Rob Davies wrote:
On Friday, September 23, 2011 3:13:02 PM Rob Davies wrote:
The reality is that users, want stability and they will be unwilling to
move to versions above 2.8.x unless there's a compelling reason to do so.
So let them stay on 2.8.x. We'll happily provide fixes for them. We have a
nice back
I just talked to Dan and Hadrian about this idea. The problem is that
however we would call such a release people would take it as kind of a
milestone and it would probably not be used much.
So it is probably better to use the 2.9 and perhaps 2.10 release for
that. The 2.x naming will suggest
41 matches
Mail list logo
