Malcolm Wallace
On 3 Dec 2012, at 11:35, Herbert Valerio Riedel wrote:
2) there's a package text-foo which depends on 'text >= 0.10' (i.e. with no upper bound), for which N versions exist on Hackage (all with the same 'text >= 0.10' constraint):
0.1.0, 0.1.0.1, 0.1.0.2, 0.1.1, 0.1.2, 0.2, ...some more... , 0.7.2.2, 0.7.2.3
4) text-foo-0.7.2.3's .cabal file is updated server-side to have the version constraint set to 'text >= 0.10 && text < 0.11'
Alas, 4) isn't enough, as it leaves N-1 versions of text-foo with an invalid version constraint
I don't understand why you suggest that only the most recently uploaded version of text-foo would have its cabal file updated on the server. If the scheme is going to work at all, it must update _every_ version of text-foo that could be affected.
(...in contrast to conservative-bounds, for which the integrity wouldn't break if one doesn't update *every* version of text-foo with relaxed bounds -- it would just artificially reduce the reachable space of compatible package/version combinations)
Is that an unrealistic expectation?
I don't know... I guess it depends on how much the process of making the version bounds stricter can be automatized, as otherwise it's a potentially tedious task that would make it easy to miss something, and thus not fully re-establish the inter-package version-constraint integrity. Some kind of automatization would also be important in order to keep the time window as small as possible when Hackage (in its current implementation) loses temporarily its inter-package integrity due to uploads of new packages with breaking API changes. cheers, hvr