Re: configId issue... tooling impact

[Sachin Patel]

After thinking about this some more... I'm retracting my statement.  Regardless of what incompatibilities or migration steps that will need to be taken in future releases, Geronimo 1.0 is an official release and thus there should always be associated tooling to go along with it.  I think removing the G1.0 support and simply replacing it with G1.1 deployment support is the wrong thing to do and instead G1.1 support should be cumulatively added.  Even though this bodes a little more work I think it is the right thing to do.  Therefore rather then delay the release of the eclipse plugin, I feel that I should go ahead and freeze and release the plugin as-is.  Then as soon as G1.1 is release I will provide via update manager a new version of the feature which supports G1.1. Now since the deployment plan editors in the current plugin are very limited and incomplete, and the fact that G1.1 configId changes will affect the UI, my current thinking is to replace the G1.0 deployment plan models with G1.1 in the 1.1 version of the plugin.  This means that the G1.1 plugin will list both G1.0 and G1.1 as a runtime type and a server type, but only selection of G1.1 will contain support for the editors. If there are not any objections within 24 hours I will officially release the 1.0 version of plugin. - sachin On Feb 4, 2006, at 10:32 AM, Sachin Patel wrote: So due to the planned configId changes for 1.1, this will have a direct impact on the tooling.  The primary issue here is that the 1.0 eclipse plugin is soon to be released only to be broken immediately by the release of 1.1.  So rather then release a plugin that will not work with 1.1 here is my proposal... As soon as WTP 1.01 is released I had planned to go out with the 1.0.0 plugin.  Instead I'll just tag it and make that binary available as a stable driver "zip only" (But won't put it on the update manager site which kinda puts a commitment that feature updates and patches on this will need to me made thereafter.)   I'll then start versioning all my runtimes and servers to 1.1, wait for the configID changes, migrate the code and do a full release (update manager site included) as 1.1 which will allow you to define ONLY a 1.1 runtime and 1.1 server. In normal circumstances, every major release should be listed in the plugin (i.e create a 1.0 server, 1.1, server, 2.x, ...), however given the impact on the incompatibilities introduced, and specifically the possibility of not having any upward schema conversion magic, I think this is much more safer bet to just go ahead and replace 1.0 support with 1.1, rather then add 1.1 support as you would do normally. In the future, we need to be "tooling-aware" and for any major change going in like this to start considering the impact on tooling.  For some stuff I may be impacted but not aware of it, so I'm asking each and everyone to be more conscious about this going forward. Thanks - sachin