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 why not waiting a bit, given we have already a breaking 3.0 planned already. Trunk becoming 3.0 is actually a nice way to do that. It allows developers to continue working and making things cleaner as you do and keep a 2.9 branch for more non breaking changes / improvements / new features. On Mon, Sep 26, 2011 at 13:17, 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. > > 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. > > 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 > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
