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. For changing the behaviour of names (as opposed to adding new behaviour with new names) this does get quite drawn out, though. Another option would be to make a network-string package exporting Network.Socket.String, which depends on network and either reexports Network.Socket directly (for old versions) or wraps the ByteString functions (for new versions). Then people can make their code use network-string now (which also works with HP 2010), and migrate back to network once it's a major release or 2 old. Thanks Ian