On Sat, Apr 3, 2010 at 6:21 AM, wren ng thornton
I'd argue that it's acceptable, at least under this plan:
* fork parsec-2.1 as parsec2-2.1 * continue to develop parsec2-* (as desired) * deprecate parsec<3 with message to switch to parsec2-* * continue parsec>=3 as parsec-*
The harm is minimal because:
(a) anyone who is too lazy to upgrade their .cabal can still use parsec-2.1 until it bitrots
(b) anyone who is too lazy to upgrade their code to parsec>=3 can just update their .cabal to use parsec2-* if they want to avoid bitrot
(c) anyone using parsec>=3 won't notice a thing.
I really like this plan, so I've finally gotten something done in this direction. I pulled parsec-2.1.0.1 off of hackage and stuffed it into a fresh darcs repo, and I've made two branches off of it: http://community.haskell.org/~aslatter/code/parsec-2/parsec2/ This is a new package that I am willing to maintain. I expect to be limiting my actions to maintaing compatibility with as many GHC releases as practical, and I will accept patches needed to get working on other implementations. Fixes such as Greg's above are also appropriate when kept in sync with main-line. http://community.haskell.org/~aslatter/code/parsec-2/parsec-deprecated/ I propose to upload this to hackage as parsec-2.1.0.2. It is identical in all respects to 2.1.0.1, except each module is marked as deprecated, producing the following warning: Text/ParserCombinators/Parsec/Language.hs:27:0: Warning: In the use of type constructor or class `LanguageDef' (imported from Text.ParserCombinators.Parsec.Token): Deprecated: "Please use the parsec2 package or upgrade to a higher version of parsec" Any comments on either of these two branches? Is parsec2 the right name for the branch package? Does anyone want to see anything different in the package description text? Is the next step getting parsec2 into the Platform, and updating inter-platform deps? Take care, Antoine