A-posteriori .cabal updates don't help (much) with optimistic-upper-bounds

[Herbert Valerio Riedel]

Malcolm Wallace <malcolm.wallace at me.com> writes:

> 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