Ian Lynagh
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