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 SPI changes I propose
(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.
So while there is a chance that people are hit the percentage may be
small. If we then react fast or even before 2.9.0 and provide
compatibitlity for people who report problems then I can imagine to make
almost everyone happy with 2.9.0.
Christian
Am 26.09.2011 10:52, schrieb Claus Ibsen:
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 we aren't, as long as we document the not backwarts
compatible changes.
The API changes has not been fully documented. In fact there is a
"disclaimer" in the release notes, saying something like.
Hey we have changed the API a lot, and we kinda got lost in this
process. We are sorry if you hit any API breakings.
But tell us and we will try to add some stubs in the next release.
A micro/bugfix release has to be 100% backwarts compatible of course.
The current 2.8.x branch is not 100% backwards compatible. There is
API changes committed.
I prefer to release a 2.9.0 version after Christian S. (an may other) 99%
backwarts compatible changes/refactorings are done. Afterwards we can start
to develop 3.0.0 on trunk - with the time to play a bit with our new ideas
and the freedom to break existing APIs.
Well if Christian did stop right now doing anymore API changes, then
we may have a slight chance to not piss-off to many end users.
But there is JIRA ticket assigned to him targeted for Camel 2.9.0,
where he wants to do bigger API-breakings in the model / SPI packages.
Likewise he moved classes / deleted classes (from camel-core) without
marking any old classes as @deprecated, which gives people a chance to
migrate over a amble period of time. So we end up in a catch-22
situation.
Can you report the classes you found. If they are important to users I
can provide stubs.
So Camel end users may have developed in-house components /
interceptors / management tooling / or whatever for Camel which you
want to use for existing in production Camel 2.8 projects. And then
also for new projects using Camel 2.9+. For that to work out, you
would need to maintain 2 branches of your custom stuff as its not
compatible with both 2.8 and 2.9+.
Yes that can be a real problem. So we should make sure there are not too
many releases that change the API on the way to 3.0. On the other hand I
think we should release often to get feedback. That is a difficult balance.
Christian
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
