Add to Stackage

[ndmitchell]

Useful for installing with Stack. I'm happy to be the stackage maintainer if you want, but obviously you'd be a better choice.

[mpickering]

I don't want to be the stackage maintainer, it is too annoying to get the notifications.

[ndmitchell]

If you set lots of upper bounds, then yes, it gets annoying, but there's a solution to that 😉. I'll add it to Stackage with my name.

[dwijnand]

What's the solution? Not set any or many upper bounds?

[ndmitchell]

To a first approximation, yes. My solution is to set upper bounds where I think the likelihood of breakage when something changes is high and the notice I'll get is low. For example, I think base tends to break something in things like Shake with each release, but I get lots of advance notice, so no upper bound needed (although Cabal forces a silly one). For haskell-src-exts, I'm fairly sure its going to break HLint, so I put an upper bound. For things like text, hashable, unordered-containers, I'm using the most vanilla of vanilla features from them, so I suspect the new version will be compatible, leave off the bounds and then respond after the fact with Cabal revisions and a new release. It keeps the day to day busy work down, and only very rarely breaks. I've been broken by 0.0.1 releases (the "non-breaking" kind) as much as I have by 0.1 releases, so I've no way to guess what the upper bound should be anyway.

[istathar]

I only maintain occasional lower bounds in my projects when really necessary (like to force the latest version of something where I know I have an incremental dependency on a new feature). I then do

stack upload --pvp-bounds=both .

when sending the package to Hackage, however, and it annotates the uploaded .cabal file with appropriate bounds based on whatever Stackage resolver snapshot I've built from. Makes Hackage maintainers happy and makes me happy not dealing with constant upper bound bumps.

[ndmitchell]

It's in Stackage.