[Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

[Carter Schonwald]

As someone who recurrently is nudging a large number of maintainers every
major ghc release to bump their bounds, I favor the no upper bounds
approach! :)

plus the whole improving ecosystem of build bot tools which play nice with
cabal et al that are cropping up mean that "in principal" we could debug
missing upper bounds via sort of temporal bisecting over the "event stream"
of maximum available versions at a given time to sort that. (but that piece
isn't that important)

more pragmatically, cabal when used with hackage doesn't let you override
version constraints, it just lets you add additional constraints. This
makes sense if we assume that the library author is saying "things will
definitely break if you violate them", but in practice upper bounds are
made up guesstimation.

YES, its presumably semantic versioning doesn't create a problem, but with
the hackage eco system, when dealing with intelligently engineering libs
that are regularly maintained, version upper bounds create more problems
than than solve.

just my two cents. (yes yes yes, please drop upper bounds!)

cheers
-Carter

On Wed, Aug 15, 2012 at 5:04 PM, Michael Blume <blume.mike at gmail.com> wrote:

> > it's usual for the existing upper bounds to refer to versions that don't
> exist at the time of writing (and hence can't be known to be stable).
>
> Well, known to be stable given semantic versioning, then.
>
> http://semver.org/
>
> On Wed, Aug 15, 2012 at 1:55 PM, Bryan O'Sullivan <bos at serpentine.com>
> wrote:
> > On Wed, Aug 15, 2012 at 1:50 PM, David Thomas <davidleothomas at gmail.com>
> > wrote:
> >>
> >> Would it make sense to have a known-to-be-stable-though soft upper bound
> >> added proactively, and a known-to-break-above hard bound added
> reactively,
> >> so people can loosen gracefully as appropriate?
> >
> > I don't think so. It adds complexity, but more importantly it's usual for
> > the existing upper bounds to refer to versions that don't exist at the
> time
> > of writing (and hence can't be known to be stable).
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120815/53011305/attachment.htm>