RFC: Extended version-range descriptions for Cabal

[Thomas Schilling]

On Mon, 2007-09-24 at 22:02 +0100, Ian Lynagh wrote:
> On Mon, Sep 24, 2007 at 09:53:16PM +0200, Thomas Schilling wrote:
> >
> > can lead to rather awkward descriptions of common version ranges, for
> > example,
> > 
> >   base >= 1 && < 2 
> 
> I don't think anything more is needed, but...
> 
> > (1) Wildcards:
> > 
> >   1.*   ~~>   >= 1 && < 2
> > 
> > in general
> > 
> >   m.n.o.*   ~~>    >= m.n.o && < m.n.(o+1) 
> 
> I have no objections to this.
> 
> > Note, that the translation is not ">= 1.0 && < 2", because that would
> > exclude version "1", as [1] < [1,0] == True.
> 
> I'm not convinced that that isn't a bug.

Ack, me neither.


> > (2) Ranges:
> > 
> >   1 - 2.1   ~~>    >= 1 && <= 2.1
> 
> I don't like that. I don't think someone writing that means to not
> include 2.1.0.0.1.

Well, this leads to the issue if versioning schemes make promises about
compatibility, and if so, whether Cabal should deal with those.

For example, using the common scheme

  major.minor.patch-level

Cabal should not use "foo 2.1" to satisfy "foo >= 1" as it might be (and
likely is) incompatible.  But it should always use "foo 1.2.3" to
satisfy dependency "foo 1.2", but not necessarily "foo 1.4".  We could
allow giving semantics to versioning schemes like this, but I am neither
sure what the details should be, nor if this would really be worth it.

As a compromise, this special case could be disallowed, by forcing the
pattern

  m - n.*    ( or:  m .. n.* )

but I guess that this would seem like an unnecessary restriction.

> 
> > If the upper limit is supposed to be exclusive, this can be combined
> > with (1):
> > 
> >   1 - 2.0.*  ~~>  >= 1 && < 2.1
> 
> This reads very oddly to me.
> 
> > I'd like include this into Cabal-1.2 which is scheduled with the next
> > ghc release, so it can fearlessly be used when getting packages ready
> > for GC 6.8.1.
> 
> I'd prefer we had more time to consider the syntax, as we don't want to
> be stuck with supporting whatever we come up with in the eleventh hour.

Fair enough.  If people agree that it's not that useful or can't easily
agree on what it should look like, I will not push it.  I think at least
(1) is uncontroversial and (2) would be a nice-to-have for the 'base'
package.

/Thomas