Sure, at least I can try and get the ball rolling ;) btw. I cc'ed in jbosstools-dev too since it relates to tooling in general too. The discussion we had is rooted in the realization that we live in a world where developers will use multiple versions of our projects when developing. E.g. They do "SuperShopperApp v2.0" using EAP 4.3, Hibernate 3.2, Drools 3 and JBPM 3, but last year they used JBoss AS 4.2, Hibernate 2.0.5, Drools 2 and JBPM 3 in "SuperShopperApp v1.0" and next year they plan to use EAP 5, Hibernate 3.3 or maybe 4, Drools 5 and JBPM 4. How would a developer expect these thing to work in their tooling environment ? (note: I'm explicitly ignoring the build problem here e.g. how they handle different jars etc. I'm just talking about tooling). I believe that they would expect to use the same IDE for browsing and using these customer projects, just like you probably assume that you could develop both JDK 1.4, 5, 6 and maybe even 7 with the same IDE. The tools does not have a bounded monolithic life cycle like frameworks has, frameworks normally need/tries to be 100% compatible with it self betwen the micro version updates (2.1.2 to 2.1.3), mostly compatible between minor updates (2.1 to 2.2) but "nothing" is promised between major versions (2 to 3). Tools does not have that freedom. The comon way of solving that in IDE's is that the tool has a notion of runtimes and possibly also settings applicable to specific versions, e.g. in Eclipse you can setup a set of JDK's and where they are located plus you have a set of settings that can tweaked that might or might not apply to all versions of their runtimes. Look for Java Compiler settings and Installed JRE's in Eclipse preferences for examples. Examples of tools in JBossTools that has this notion is JSF tooling JBoss AS, Seam tooling. They have the notion of JSF 1.1, JSF 1.2, AS 4.0.5, AS 4.2, AS 5, Seam 1.2 and Seam 2 etc. Examples of tools that does not have this notion (to my knowledge) is Hibernate, jBPM and Drools. For Hibernate it have not been a big issue since it targets Hibernate 3.x and the Hibernate project has always (except a few minor glitches) been backwards compatible and thus the input and output for Hibernate Tools have not been problematic. When Hibernate 3.3 and possibly Hibernate 4 comes out we will probably run into some problems that needs to get solved (luckily I know how for most of them ;) jBPM is targeting jBPM 3.x and has also more or less been backwards compatible and there haven't been any 4.x (yet). Now 4.x is in the works then the tooling should start adjusting for having to handle two different versions. Drools has already had its share of problems ;), e.g. Drools 3, 4 and soon 5, and you cannot use the Drools 4 plugins with Drools 3 projects etc. Or rather you can, but since the editor is highly coupled with the drools version we run into problems if the syntax changed too much between versions, similar problems occur when using the debugger which assumes certain methods/structures exists in the remote debugged vm. We have discussed some times before and I keep hearing that we have too few resources to handle this and it is not relevant to do for X project. But I don't buy that argument ;) Sure we always will have too few resources, but this is relevant for any project that wants to be used over a long period of time plus I believe it is a minimal effor that is required to handle it in *most* cases. I'm not talking about being 100% compatible with everything you ever released - I'm just talking about having the notion of having multiple major versions and if necessary minor versions if your underlying framework is being evil and breaking things in minor releases. /max