Hello,

Don Stewart pointed out to me today that our hashed-storage constraint is
overly constrained.  It's good that we provide a lower bound that takes into
account the necessary bug fixes, but we are not taking into account bug fix
releases of hashed-storage that become available after a darcs release.

This patch fixes that by specifying an upper bound.  I'm also making the
assumption that hashed-storage will follow the PVP:
  http://www.haskell.org/haskellwiki/Package_versioning_policy

Thanks,
Jason

Attachments

• darcs_cabal_-provide-reasonable-upper-bound-on-h_s.dpatch
• unnamed

On Thu, 12 Aug 2010, Jason Dagit wrote:

> Don Stewart pointed out to me today that our hashed-storage constraint is
> overly constrained.  It's good that we provide a lower bound that takes into
> account the necessary bug fixes, but we are not taking into account bug fix
> releases of hashed-storage that become available after a darcs release.
>
> This patch fixes that by specifying an upper bound.  I'm also making the
> assumption that hashed-storage will follow the PVP:
>  http://www.haskell.org/haskellwiki/Package_versioning_policy

This is a deliberate policy (suggested by me, I think) to reduce confusion 
about whether a specific version of darcs would have a specific 
hashed-storage bug fix or not. Otherwise you have to identify both the 
darcs version and the h-s version in every bug report. In other words we 
specifically don't want to pick up bug fixes without revving darcs too.

Obviously the same argument might apply to many other packages we depend 
on, but h-s has a fairly unique position in that it's quite critical to 
darcs and also relatively fast-moving.

We can of course discuss the policy further, but I just wanted to be clear 
that it was a deliberate decision, rather than ignorance.

Cheers,

Ganesh

On Fri, Aug 13, 2010 at 00:35:14 +0100, Ganesh Sittampalam wrote:
> This is a deliberate policy (suggested by me, I think) to reduce
> confusion about whether a specific version of darcs would have a
> specific hashed-storage bug fix or not. Otherwise you have to
> identify both the darcs version and the h-s version in every bug
> report. In other words we specifically don't want to pick up bug
> fixes without revving darcs too.

I regret that despite a bit of darcs changes searching and Googling, I
could not find an archived discussion on this.  But I guess now we have
such an archive for future use!

I seem to remember that the discussion took place in the Zurich
Darcs hacking sprint <http://wiki.darcs.net/Sprints/2010-03>
(I didn't see any mention there, except that hashed storage was
on the agenda for things to talk about)

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
For a faster response, please try +44 (0)1273 64 2905.

I'm closing because no one else has yet (and I think it's rejected due to 
a policy decision?).

Jason