(This is intended to be a serious, though partially-complete, proposal. I offer it in the hope it starts a constructive discussion.) The rapid changes in GHC have both good and bad aspects. I am specifically discussing proposals which break existing code. My goal is to offer ground rules to make changes easier to implement by easing the pain they cause to current programmers, their existing code and language learners. _DESIRABLE_ FEATURES OF GHC CHANGES: 1. Breaking existing code should be avoided UNLESS a simple method is provided to continue to compile the old code for a reasonable transition period. 1a. Corollary: When changes are made to the Prelude, provision should be made to allow the older Prelude(s) for a reasonable transition period, so existing code can be used during a reasonable transition period. 1b. Corollary: Since GHC changes (especially to the Prelude) will require changes in commonly used libraries, which will take time to complete and stabilize, the transition period should be long enough to incorporate this as well as changes to programs using these libraries. 1c. Corollary: A suitable subset of code on Hackage should compile either under the changed feature or (by a simple method) the prior feature for a reasonable transition period. Any failure of this subset to compile should be an absolute stop to releasing a new version of GHC. 1d. Corollary: Haskell 98 and Haskell 2010 standard-conforming code should compile either under the changed feature or (by a simple method) the prior feature for a reasonable transition period. Any failure of standard-conforming code to compile should be an absolute stop to releasing a new version of GHC. (Reason: Currently available books and other teaching material still generally are written to conform to Haskell 98. It is desirable to allow language learners to compile code included in their existing learning materials to reduce their learning curve.) 2. One method of satisfying (1) is to include compiler flag(s) to select various versions of Haskell Preludes and commonly used libraries compatible with those Preludes. Alternatively, other simple methods are acceptable. 3. It is desirable to provide automated tools that will update existing code to the newer Prelude and libraries. The existence of such tools will influence the length of the transition period. DISCUSSION 1. Adoption of Haskell is retarded by difficulty learning the language, which is increased if learning materials don't compile. 2. Adoption of Haskell for production use is retarded by GHC changes that break existing code, necessitating ongoing maintenance. This can be ameliorated by automated tools to update existing code. 3. If GHC developers and library maintainers consider the impact of their changes and seek to minimize their immediate and longer-term impact, this will enable greater adoption of Haskell which will expand the Haskell community to everyone's benefit.