Bump version to > 0.5.1 and upload to hackage

[ygale]

Thanks to great work by @phadej we now support GHC 8.8.1 and modern versions of network. Yay! But the version number in the cabal file is still the same as before, 0.5.1, and none of this is available on Hackage. Could you please just bump the version and upload? Thanks!

[jtdaugherty]

Thanks for asking. I definitely appreciate the work done by others on this package and the desire to have it updated on Hackage. However, I am concerned about releasing it to Hackage because this package is not maintained. From the README:

NOTE: I am seeking a maintainer for this package. If you are interested, let me know!

If someone wants to volunteer to do a review of the unreleased changes, then I would be happy to make a release after that review is done. Until then, I'd like to hold off:

To me, part of maintenance is carefully reviewing all of the changes that are released from various angles (correctness, security, etc.). Since I have not had time to maintain this package for some time, I have not had time to do that review. Without that review, I think a release to Hackage would not be responsible and the community could potentially suffer if upgrading to a version of this package that has not seen adequate inspection. I think that until a new maintainer is identified and can spend time reviewing the state of this package, it should be used with caution and it should be used only deliberately.

The last well-formed release was in 2016. There have been many changes since, which were accepted in the spirit of keeping the package moving forward as interested contributors stopped by. Those changes have gotten varying levels of attention from a number of folks, including @lemol who maintained this package for a time but who has seemingly not had time or been available for quite a while. I would definitely love it if someone wanted to step up and take ownership of this package -- someone with the time to do so, and someone with the technical knowledge to be a good steward of the codebase (neither of which I can provide).

[ygale]

@jtdaugherty I'm not sure where you got the idea that uploading to hackage implies any sort of obligation. When hackage was first created, it was explicitly stated that this is not the case. The purpose of hackage is to make it easier for people to use libraries, not to make promises.

Uploading to hackage saves people work. When the HaskellNet version on hackage is out of date, we need to manually manage build files, test versions, and pin them. This adds up to a significant cost over time. You can bump the version and upload it in literally a minute or two, and save many people many hours of work. Why not just do it?

This is a great library. Many people are using it - and contributing, as you see. We all appreciate the good work you have done in the past, and we don't hold you responsible for anything going forward. Thanks!

I share your hope that a serious maintainer will step up to the plate and push the library forward. But in the meantime, your "light touch" maintenance mode has been working fine, and the library continues to be widely useful.

[ygale]

If you're OK with a bump to version 0.5.2, I created PR #65

[jtdaugherty]

Uploading to hackage saves people work.

You can bump the version and upload it in literally a minute or two, and save many people many hours of work. Why not just do it?

That's a good question, and I agree that uploading can save people work. Taken by itself, I share your view of that as a good thing. But uploading code to Hackage that has not been vetted, and which is going to be readily used by any package with sufficiently loose constraints, poses a security risk to any application that uses it. So while it might be just a minute of work for me to upload an unvetted release, it could potentially create a serious amount of work for users if issues arise. I can appreciate the founding vision of Hackage, but that vision does not supersede good maintenance practices. "Easily upload code of unknown provenance" is not more virtuous than "be conservative in what gets uploaded for the benefit of the entire community."

I'm glad people find this library useful! Personally, I think it needs a lot of work and I have some skepticism about the correctness and security of the codebase based on the issues I encountered and based on the many issues people have run into when using the package.

Again, I'm not refusing to upload a new version in general; I'm saying that a careful review of the changes is preferable to a blind upload.

[k0ral]

Considering that this issue has been opened for several months, and in the interest of having things move forward, may I suggest some alternate trajectories that you might be more comfortable with:

• EITHER let's release the new 0.5.2 version while excluding it from the preferred-range; this way, version 0.5.1 will be picked by cabal unless 0.5.2 is explicitly requested; this defers the responsibility of upgrading, to the users of the package, and makes it possible for the early adopters to give feedback / raise issues;
• OR let's backport the changes required for this package to be GHC-8.8.1-compatible on top of 0.5.1, and release that as 0.5.2; I don't know the extent of these changes, but I'm willing to help if needed

[jtdaugherty]

Thanks for your proposals, @k0ral. I took the first path uploaded the latest changes in 0.5.2 and deprecated it.

[k0ral]

I see that you set 0.5.2 as deprecated, rather than setting preferred-range to <0.5.2 . Is that intended ?

[jtdaugherty]

I assumed one was functionally equivalent to the other. I'm happy to update the preferred range!

[jtdaugherty]

(Looking at http://hackage.haskell.org/packages/preferred it at least appears that marking things as deprecated has the desired effect.)