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 > > 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.
I completely agree and support that. Seriously, once Hadrian (endpoint config changes), Christian (api cleanup), and Claus (parsing things) have things roughly settled down and close to done, I'm all for an RC or 2. It maybe a bit premature *right now* as there are things they know about that are still being addressed, but in a week or three, it sounds like a great idea. Dan > > > 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. > > 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? > > > 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 -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
