[Seaside-dev] 3.1 repo?

[Julian Fitzell]

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.

If we "postpone" it, there's no chance of having it done for the summer.

Julian