Changing the API of the network package to use ByteStrings instead of Strings

Gregory Collins greg at gregorycollins.net
Sun Oct 31 15:37:19 EDT 2010


Ian Lynagh <igloo at earth.li> writes:

> On Sun, Oct 31, 2010 at 04:38:25PM +0100, Johan Tibell wrote:
>> 
>> 1. Warn people of the upcoming change e.g. 6 months in advance, and
>> then just change the types as part of a HP release. Delete the
>> *.ByteString modules.
>> 
>> 2. Deprecate the String based functions using pragmas, slowly move
>> people over to the ByteString based ones. When everyone has moved
>> over, change the types of the original functions to also use
>> ByteStrings. Slowly migrate people back to the old functions (that now
>> have a different type). Delete the *.ByteString modules.
>> 
>> To be honest, I don't think 2 will ever work. From experience, without
>> a deadline, people wont move.
>
> You can have an overlap period and also deadlines. e.g. if HP major
> releases are yearly, then this would work for people wanting to support
> 2 major releases at all times:
>
> HP 2011: Add Network.Socket.ByteString.
> People wishing to support 2 major versions use Network.Socket.
>
> HP 2012: Deprecate Network.Socket.
> People wishing to support 2 major versions use Network.Socket.ByteString.
>
> HP 2013: Make Network.Socket use ByteString.
> People wishing to support 2 major versions use Network.Socket.ByteString.
>
> HP 2014: Deprecate or remove Network.Socket.ByteString.
> People wishing to support 2 major versions use Network.Socket.

Three years? Ouch. I'd vote for a "tough love" approach, namely: bump
the major version number of network, remove the String functions from
Network.Socket immediately, and move them to
Network.Socket.String. Rather than going through N deprecation cycles,
why not just get on with it, like ripping off a band-aid? There's no
reason old code couldn't continue to depend on network-2.*. And the
upgrade path for lazy maintainers or people who want to stay on String
is trivial.

At the very least I would opt for Johan's first approach, namely
deprecating the string functions with a 6-month deadline.

If packages are following the PVP properly they shouldn't be pulling in
network-3.* anyways. But of course, lots of projects probably use
unqualified "network" imports; maybe we could grab some numbers on how
many Hackage libs would break?

G
-- 
Gregory Collins <greg at gregorycollins.net>


More information about the Libraries mailing list