[Metacello] Re: [Seaside] BlockClosure>>processHttp {*KomHttpServer}

Dale Henrichs dhenrich at vmware.com
Tue Feb 15 22:54:36 UTC 2011


Germán,

If folks are _supposed_ to use the version that you have just created, 
then it is correct to define it as #stable.

In the past, whenever you (or anyone else) released a new version (i.e., 
blessing was not #development, #broken, or #baseline) everyone that 
loaded the package using #latestVersion would pick up your version ... 
and noone ever thought of the implications.

Now that we have a #stable symbolic version folks are thinking of the 
implications of their actions:)

That is good, because when specifying a version as #stable, you must 
think about the target platforms and the versions of the particular 
platforms.

If the change you have made was aimed at making Kom run on Pharo1.2, 
then it makes sense to declare that your new version is #stable for 
Pharo1.2.

If you have only tested your change on Pharo1.2 (for example), then it 
would be prudent to declare 1.0.8 as stable for Pharo1.2, even if you 
_think_ that it will work on all supported platforms.

If you are comfortable that the change you have made applies to all 
supported platforms, then declare 1.0.8 as #stable for #common....


Dale

On 02/15/2011 01:02 PM, Germán Arduino wrote:
> Hi Dale!
>
> I was precisely thinking about this question.....who decides what
> version is #stable for example (in a package that is not owned by the
> guy that modify the configuration)? I was tempted of qualify as
> #stable the 1.0.8 of Kom because includes the #fixTemps fix,
> but....but who knows the other implications that they may bring.
>
> Just thinking about......
>
> Germán.
>
> 2011/2/15 Dale Henrichs<dhenrich at vmware.com>:
>> Germán,
>>
>> Good. I am working on the configuration for Seaside3.0.4 and in the process
>> I will make sure that all of the symbolic versions are updated correctly ...
>> The Seaside3.0.4 configuration will make use of symbolic versions whereever
>> necessary.
>>
>> Dale
>>
>> On 02/15/2011 10:11 AM, Germán Arduino wrote:
>>>
>>> Hi:
>>>
>>> I added a new ConfigurationOfKomHttpServer:
>>>
>>> Added version '1.0.8'. It load KomHttpServer-pmm.64.mcz that solves
>>> the deprecated #fixTemps in BlockClosure>>processHttp.
>>>
>>> I not modified the #stable version, then to load the 1.0.8 call:
>>>
>>> (ConfigurationOfKomHttpServer project version:'1.0.8') load.
>>>
>>> Cheers.
>>>
>>>
>>> 2011/2/7 Germán Arduino<garduino at gmail.com>:
>>>>
>>>> Thanks by the response Philippe, will check.
>>>>
>>>> Cheers.
>>>>
>>>> 2011/2/7 Philippe Marschall<philippe.marschall at gmail.com>:
>>>>>
>>>>> 2011/2/7 Germán Arduino<garduino at gmail.com>:
>>>>>>
>>>>>> Hi Folks:
>>>>>>
>>>>>> Working with xmlrpc, at server level, I noted that even the latest
>>>>>> version of Komanche (KomHttpServer-pmm.63) use #fixTemps (for example
>>>>>> in #procesHttp method in BlockClosure). Being that #fixTemps is
>>>>>> deprecated, is correct that is already there?
>>>>>
>>>>> Nope it isn't. It should be on BlockContext but not BlockClosure it
>>>>> fixed that a while ago but apparently missed one. Anyway
>>>>> KomHttpServer-pmm.64 should be good.
>>>>>
>>>>> Cheers
>>>>> Philippe
>>>>> _______________________________________________
>>>>> seaside mailing list
>>>>> seaside at lists.squeakfoundation.org
>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>>>
>>>>
>>
>>



More information about the seaside mailing list