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 >>> >>> >>> >> >> >> -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
