geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Patel <>
Subject Re: configId issue... tooling impact
Date Mon, 20 Feb 2006 16:51:24 GMT
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

View raw message