[Seaside-dev] 3.1 repo?

[Philippe Marschall]

2010/10/25 Dale Henrichs <dhenrich at vmware.com>:
> On 10/23/2010 10:47 AM, Philippe Marschall wrote:
>>
>> 2010/10/5 Philippe Marschall<philippe.marschall at gmail.com>:
>>>
>>> 2010/10/5 Julian Fitzell<jfitzell at gmail.com>:
>>>>
>>>> I've seen a couple of commits come in to the 3.0 repo... should we be
>>>> using the 3.1 repo now or...?
>>>
>>> I believe so but:
>>>  - When that happens all deprecated methods need to go
>>>  - We need to decide whether we want to change codec semantics
>>> (they're currently in 3.1)
>>
>> Bump, let me summarize what that would probably mean:
>> - GRCodec>>  #encode: would take a String and answer a ByteArray
>> - GRCode>>  #decode: would take a ByteArray and answer a String
>>
>> The advantage of that would be to have a better, clear separation of
>> byte oriented data (ByteArray) and character oriented data (String).
>> This would potentially help to catch encoding errors earlier.
>>
>> Here's a guess what the implications of this are based on the
>> individual dialects:
>>
>> Pharo:
>> All TextConverter (WAPharoGenricCodec) based converters would stop
>> working (anything but UTF-8 and ISO-8859-1). If needed, they could be
>> rewritten.
>>
>> VW:
>> AFAIK would better work with their existing infrastructure.
>>
>> GemStone:
>> Would probably have to change their UTF-8 code. AFAIK some of it is
>> primitive based so that might get a bit awkward.
>
> Yes. Even more awkward now that we are gearing up for a GemStone 3.0 release
> next summer...which means that we're not planning to add new features to the
> new 2.x line unless necessary ... If Seaside3.1 will be in development
> through next summer then it wouldn't be too hard to accomplish, but we'd
> like to have the decision made before the end of this year (that's when our
> beta is planned)...

Given how terrible we are at planning and the consequences of this
change I propose to postpone it.

Cheers
Philippe