geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: configId issue... tooling impact
Date Mon, 20 Feb 2006 22:22:50 GMT
I think your plan makes sense.

Sachin Patel wrote:
> 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