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 much higher.
Christian
Am 26.09.2011 16:16, schrieb Guillaume Nodet:
RCs could be good, but again and imho, they'd be better focused on 3.0 than
2.9.
And from a user point of view, it seems more intuitive to have RC when you
have a big release (because you expect some changes) rather than a minor
one.
On Mon, Sep 26, 2011 at 16:08, Hadrian Zbarcea<hzbar...@gmail.com> wrote:
A couple of RC releases would work.
Hadrian
On 09/26/2011 09:37 AM, Claus Ibsen wrote:
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
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.
With the current state of trunk as Camel 2.9.0, then I actually share
a view to release early to give the community a chance to give it a
spin.
Also because Camel 2.9.0 is *not* going to be like any other regular
minor releases we usually do.
So doing 1-2 RC releases could be a good thing for the community.
Sounds good.
About the SPI changes I propose
(https://issues.apache.org/**jira/browse/CAMEL-4475<https://issues.apache.org/jira/browse/CAMEL-4475>).
This would of course
be
a breaking change for anyone who actually uses these interfaces. The
questions is though how many people
would be hit. If you look closely at the interfaces then Policy is the
only
one that is really likely to be used. The Debugger is probably also
used
especially for tests. These were the only two points where I had to do
changes outside of camel-core to get the tests working.
The SPI package is used for integrating interceptors
(InterceptStrategy) as well as Policy, which is more common used.
The Debugger API is a recent addition which allows you to debug from
unit tests (as a kind of poor mans debugger), as
well it allows 3rd party to build tooling for Camel in this area which
people in the community ask for.
How to get insight and debug their Camel apps. See for example that
survey.
You could even create an interactive debugger in Karaf Plugin, or have
some integration from the Camel web console etc.
I agree that this is a fairly new addition, and not so much used, so
if it was *only* this area that was affected. Then we may
be able to go ahead.
But interceptors is used much more by people, and I am not keen on
breaking those APIs.
I guess there is no way to have support for both in the SPI, so we
have the old API, as well as any new API?
We can have both versions but it is quite tricky to do it well.
For example spi.Policy. To keep compatiblity I can not rename or change
the
existing interface. So I have to find a name and place for the new
version.
Possible solutions:
1. spi.NewPolicy
2. spi.policy.Policy
I don´t like the first solution whatever it is called. It would only make
sense if we found a better name for it which I doubt.
Yeah I cannot at first hand see any obvious good solution. Introducing
a NewXXX seems like a big temporary solution, as the NewXXX eventually
will replace the old API. So when this happens people have to migrate
yet another time.
The second solution is better. If we find a good package name where a
subset
of the interfaces can go it can make sense. Still I am not sure about it.
The spi is a good package name. If there is a better package name for
the future, then that could be a solution.
As the existing spi, and the new package can co-exists.
So if it is only a problem for very few people then I would opt for
simply
doing an incompatible change. But this is a really difficult question.
Interceptors is used a fair bit. So its not just a few people.
Then there is the DSL like:
from("").policy(myPolicy)
There we could support methods for the old and new interface so that
should
be easy. I think we could use an Adaptor from the old interface to the
new
interface to minimize code changes.
Okay what if the SPI / model stays as is for Camel 2.9.
But having clearly notice in the release notes, javadoc etc. that
there is changes planned.
Then for Camel 2.10 we can possible look into some sort of adaptor
solution.
Maybe as a camel-adapter JAR you need to include on the classpath.
Which has the old API, and delegates to invoke the new API.
But again I don't know a good solution. Just throwing up a ball in the
air.
So the biggest problem is the naming and placing. I am open for any
suggestions.
Christian
--
--
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
