On Fri, Apr 23, 2010 at 11:34 AM, John Goerzen <jgoer...@complete.org>wrote:
> > A one-character change. Harmless? No. It entirely changes what the > function does. Virtually any existing user of that function will be > entirely broken. Of particular note, it caused significant breakage in the > date/time handling functions in HDBC. > > Now, one might argue that the function was incorrectly specified to begin > with. But a change like this demands a new function; the original one ought > to be commented with the situation. > > My second example was the addition of instances to time. This broke code > where the omitted instances were defined locally. Worse, the version number > was not bumped in a significant way to permit testing for the condition, and > thus conditional compilation, via cabal. See http://bit.ly/cBDj3Q for > more on that one. > This is of course in part due to a strength of cabal (remember that strengths and weaknesses tend to come together). Cabal discourages testing libraries/apis at configure time. The result is that version numbers need to encode this information. We don't (yet), have a tool to help detect when a change in version number is needed or what the next version should be. We leave this up to humans and it turns out, humans make mistakes :) Even once we have an automatic tool to enforce/check the package version policy, mistakes may still sneak in. I would expect the 'T' in the time format to be in this same category.** More about that below. > > I don't have a magic bullet to suggest here. But I would first say that > this is a plea for people that commit to core libraries to please bear in > mind the implications of what you're doing. If you change a time format > string, you're going to break code. If you introduce new instances, you're > going to break code. These are not changes that should be made lightly, and > if they must be made (I'd say there's a stronger case for the time instances > than the s/ /T/ change), then the version number must be bumped > significantly enough to be Cabal-testable. > While I haven't participated in the library proposal process myself, I was under the impression that Haskell has a fairly rigorous process in place for modifying the core libraries. Is the above change too small to for that process? Did that process simply fail here? Jason
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe