[Seaside-dev] 3.1 repo?

[Philippe Marschall]

2010/11/4 Julian Fitzell <jfitzell at gmail.com>:
> On Wed, Nov 3, 2010 at 7:09 PM, Philippe Marschall
> <philippe.marschall at gmail.com> wrote:
>> 2010/10/25 Dale Henrichs <dhenrich at vmware.com>:
>>>> 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.
>
> Or alternatively, let's just do that change on a branch. Chances of us
> releasing 3.1 before summer are probably pretty low anyway and if we
> really find we want to, we can just not merge that branch in until
> 3.2.

It's the only committed so far in the 3.1 repo. We can just move it
some place else or not merge it.


Cheers
Philippe