Hello Sven, Friday, November 24, 2006, 11:01:55 AM, you wrote:
in particular, my hottest hope is that ghc 6.6.1 will be shipped with fps 0.8 as separate library that will provide both backward compatibility with 6.6 and will allow to upgrade fps without recompiling ghc itself :D
This would be a violation of the "no interface changes in minor releases" rule (though at the package level rather than the module level, assuming the split fps was core), but I think there's a strong argument for it, since development of this package is continuing outside base.
I strongly object against the violation of this rule: A lot people on this list seem to have a programmer's view only, but forget about the people packaging and distributing SW. Breaking the rule makes the life for the latter people much, much harder and would lead our numbering scheme ad absurdum.
we want to break this rule just to make packaging and distribution easier. inclusion of fps into Bse was mistake, imho, which should be fixed asap. 6.6.0 probably is not in wide use, and we propose the most compatible plan which breaks only .cabal files. these files are already broken on 6.4->6.6 switch and we just want to restore 6.4 behavior - usage of ByteString require import of FPS library. so, we will end up with two sorts of Cabal files - one for 6.6.0 and one for all other ghc versions alternative solution - continue to include fps 0.8 in Base lib, and upgrade it to 0.9 in 6.8, will mean a much more serious incompatibility when switching to 6.8. plus, it will make impossible using of fps 0.9 in about year, until 6.8 arrives Don's solution - include fps 0.9 as part of 6.6.1 Base is even more terrible - it's 100% violation of these rules so, now we need to select most gracious plan of escaping from problem created by inclusion of FPS in base lib -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com