conduit 1.0, blaze-html 0.6, wai 1.4 about stackage

[snoyberg]

Pinging @ndmitchell as well.

[byorgey]

The changes to blaze-html (very small but technically/potentially breaking, hence the major version bump) are described here: jaspervdj/blaze-html#78

[ndmitchell]

simple-sendfile has conduit < 0.6, so that's a dependency I can't fix in Hoogle - pinging @kazu-yamamoto.

[snoyberg]

@ndmitchell I've sent kazu-yamamoto/simple-sendfile#12

[byorgey]

Submitted jgm/highlighting-kate#30 .

[byorgey]

Submitted jgm/pandoc#757 .

[kazu-yamamoto]

I have released new simple-sendfile.

[jgm]

I've updated my packages (highlighting-kate, pandoc), but it
may be a couple weeks before I'm ready to release a new version
on Hackage, as I'm in the middle of some larger changes.

+++ Brent Yorgey [Feb 19 13 12:05 ]:

Submitted [1]jgm/pandoc#757 .

--
Reply to this email directly or [2]view it on GitHub.
[xJAuenYDiIoVt3LF3y6847xfpIVf5tZiAeBr2EwW_ndI4t0e6_FMswIi_XLm1ll0.gif]

References

1. jgm/pandoc#757
2. #44 (comment)

[snoyberg]

@jgm Thanks for the update. @byorgey I'm going to temporarily remove the packages that depend on pandoc and highlighting-kate so that builds can proceed without imposing upper version bounds for too long. Once the new versions are up, I'll add them back in.

[byorgey]

@jgm in this sort of situation I would usually cherry-pick the change into a new branch based on the most recent release and just release that with a minor version bump. Just a suggestion though, no rush.

[jgm]

Yes, I could do that. But it becomes a big imposition on my time
to have to make a new release every time some dependency bumps
a version. I think a couple of weeks is reasonable. I'm not sure
how Stackage works, but another way to go would be to hold off on
including blaze 0.6 until all the packages have updated.

+++ Brent Yorgey [Feb 20 13 05:40 ]:

[1]@jgm in this sort of situation I would usually cherry-pick the
change into a new branch based on the most recent release and just
release that with a minor version bump. Just a suggestion though, no
rush.

--
Reply to this email directly or [2]view it on GitHub.
[xJAuenYDiIoVt3LF3y6847xfpIVf5tZiAeBr2EwW_ndI4t0e6_FMswIi_XLm1ll0.gif]

References

1. https://github.com/jgm
2. #44 (comment)

[jgm]

I've uploaded a new version of highlighting-kate. If a delay in updating pandoc is going to cause serious problems for anyone, I'm happy to cherrypick and do a release. Otherwise we can just wait.

[byorgey]

@jgm Thanks! No worries re: pandoc, I think waiting is fine. And thanks for your awesome packages. =)

[snoyberg]

@jgm Let me fill in some explanation. I'll preface it by saying that the Stackage project is very young, and none of the ideas are set in stone, so if you have ideas on how to improve processes, I'd love to hear them.

There's a maintainer's agreement available on the Wiki: https://github.com/fpco/stackage/wiki/Maintainers-Agreement. The main point is that restrictive upper bounds causes a lot of the dependency hell problems we see, so we should avoid them. It is possible for Stackage to impose temporary upper bounds, but it's best if we can avoid it.

I like to separate breaking changes into two broad categories: trivial stuff that requires just a cabal file bump, and complex overhauls. For the latter, temporary upper bounds are a requirement. For the former, I'd prefer to just move on as quickly as possible. (Obviously, there's a lot of gray in the middle there.) This is part of the ongoing community debate as to whether preemptive upper bounds are a good thing or a bad thing. I don't think we'll solve that debate now, but one of the advantages to Stackage is that, if you decide to leave off preemptive upper bounds, you'll get notified sooner rather than later that something's wrong.

I'm aware that you never signed up for Stackage, so I hope you don't consider these notifications a nuisance. According to "the rules", it's the responsibility of the people using your packages in Stackage to make sure dependencies are up-to-date, so if you'd rather I took you off the CC lists in the future, I can do so. But I do believe the notifications are a valuable resource to let authors know of potential conflicts their users may run into.

[jgm]

+++ Michael Snoyman [Feb 20 13 10:14 ]:

[1]@jgm Let me fill in some explanation. I'll preface it by saying that
the Stackage project is very young, and none of the ideas are set in
stone, so if you have ideas on how to improve processes, I'd love to
hear them.

There's a maintainer's agreement available on the Wiki:
[2]https://github.com/fpco/stackage/wiki/Maintainers-Agreement. The
main point is that restrictive upper bounds causes a lot of the
dependency hell problems we see, so we should avoid them. It is
possible for Stackage to impose temporary upper bounds, but it's best
if we can avoid it.

I like to separate breaking changes into two broad categories: trivial
stuff that requires just a cabal file bump, and complex overhauls. For
the latter, temporary upper bounds are a requirement. For the former,
I'd prefer to just move on as quickly as possible. (Obviously, there's
a lot of gray in the middle there.) This is part of the ongoing
community debate as to whether preemptive upper bounds are a good thing
or a bad thing. I don't think we'll solve that debate now, but one of
the advantages to Stackage is that, if you decide to leave off
preemptive upper bounds, you'll get notified sooner rather than later
that something's wrong.

I'm aware that you never signed up for Stackage, so I hope you don't
consider these notifications a nuisance. According to "the rules", it's
the responsibility of the people using your packages in Stackage to
make sure dependencies are up-to-date, so if you'd rather I took you
off the CC lists in the future, I can do so. But I do believe the
notifications are a valuable resource to let authors know of potential
conflicts their users may run into.

It's very useful for me to be notified, so please keep CC'ing me.

[ndmitchell]

Hoogle 4.2.16 is out, which mostly removes upper bounds on the web framework pieces (which are evolving much faster than I am).

[snoyberg]

Great, I've added hoogle back in.

[byorgey]

pandoc-1.11 was just released (thanks @jgm !) and I've uploaded new versions of BlogLiterately and BlogLiterately-diagrams. I'm doing a test build of stackage now and will submit a pull request once I confirm everything builds cleanly.