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 why do we need to do so many large API changes in 2.9? I would much prefer keeping 2.x as stable as possible and leave the large API changes for 3.0.
Cheers, Jon On Mon, Sep 26, 2011 at 9:39 AM, Guillaume Nodet <gno...@gmail.com> wrote: > 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 > -- Cheers, Jon --------------- FuseSource Email: j...@fusesource.com Web: fusesource.com Twitter: jon_anstey Blog: http://janstey.blogspot.com Author of Camel in Action: http://manning.com/ibsen
