configId issue... tooling impact

[Sachin Patel <sp...@gmail.com>]

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

Re: configId issue... tooling impact

[Matt Hogstrom <ma...@hogstrom.org>]

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
>>
>>
>>
> 
> 

Re: configId issue... tooling impact

[Sachin Patel <sp...@gmail.com>]

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
>
>
>