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

Sebastian Sastre sebastian at flowingconcept.com
Tue Feb 15 23:45:51 UTC 2011


Good!

Curating software versions is a good signal (for any technology or project).

People will expect we manage to do it properly for every release.

sebastian

o/




On Feb 15, 2011, at 8:54 PM, Dale Henrichs wrote:

> 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
>>>>>> 
>>>>> 
>>> 
>>> 
> 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20110215/c6210ec4/attachment.htm


More information about the seaside mailing list