Preparation for the next release

[Anton-Latukha]

Currently, the main questions that I see that project has for the next release milestone are:

• CI CI: Travis: upd: maybe this would be able to help #583 default.nix: expose additional part of Nixpkgs haskell.lib API #609 default.nix: refactor, provide rest of the Nixpkgs Haskell.lib features, document #617
• GHC 8.10 Please, support GHC 8.8/8.10 #592
• Unbreak HNix in Nixpkgs Unbreak the HNix in Nixpkgs #591
• Clean-ups and updates of dependencies Unused dependencies? #588 Use haskeline-0.8 #540 Clean up hashing-related dependencies #597
• Enable package testing in CI and pass project through proper packaging procedure hnix.cabal: add tests/files to extra-source-files #615

That would stabilize our builds everywhere and stabilize relationships with dependencies and dependants, and so return the moral honor to and reestablish the project as a good citizen in the community.

---

• We also have important organizational question raized in Merge/review constraints Merge permissions #598

Currently, the constraints hugely slow down progress.

As I already put simply, for example, cosmetics, and dependency/import clean-ups, documentation. Documentation should not obey the pull request review process, it should obey the easy editing process, or the documentation and the code with it would just never merge into the repo.

It is always way easier to get the code without the documentation through the review, as many people do by default, and as many maintainers accept by default, then the documented code.

[Anton-Latukha]

@jwiegley
We can send-out a 0.8.1 now to people.
Since we achieved:

• buildFromSdist = true now works for GHC >= 8.8.3
• Even buildStrictly (so also buildFromSdist + free of warnings) on GHC > 8.8.0, so now Hackage packaging procedures indeed were properly checked.
• Nixpkg packaging of HNix (Clean-up for some packages in haskell-modules/configuration-common.nix. NixOS/nixpkgs#89513) now is unbroken, freed from old override, and respects dependencies.

We can make a minor 0.8.1 release to give proper Haskell package to the community everywhere, so everyone who willing to learn/make something would have a properly working package and Haddock Hackage documentation.

[sjakobi]

I'd like to point out that 9c6003a was technically a breaking change due to the removal of a few Haskeline.MonadException instances from the library.

It seems fairly unlikely that any users will be affected by this, but I think it's better to err on the side of caution and go with v0.9.0 for the next version.

[Anton-Latukha]

Yes, you are right, I would look closer into it.

Technically speaking any exception handling at all - is an "change of behavior of exported function", AKA if code was throwing error, or handled situation differently, and now it is more properly handled, I observe most teams still treat that as a minor change and ignore exception handling updates.

But here also indeed type class instances were removed.

[Anton-Latukha]

I think there should be a way for automatically check the most of the breaking changes, CI should be able to do that. As also submitter often knows, so should mark it as breaking change, in that way the versioning would be mostly automatic.

[Anton-Latukha]

As with GHC 8.10 so far the situation is waiting for resolution.

Now CI normally passes the sdist on 8.8 and strict build on 8.6.

I would slowly form a release.

Mainly in code there are only main/Repl.hs functional changes, to function types - replacement of type classes. Also there is no export clause in the file, so it should be 0.9.0.

[sjakobi]

Sounds great, @Anton-Latukha! :)

Do you think you could make a release branch and an accompanying PR, so @sorki and I could have a look?

Eventually, it would be great to have a changelog too, but of course, that's also a bit of work…

[Anton-Latukha]

Repl.hs is not a module exposed, so 0.8.1 then.

[Anton-Latukha]

What is hard in Changelog? With the right lazy verbosity of it.

In reality, people care and should be informed only about breaking changes in Changelog.

And Haskellers would pick a Changelog that talks only about breaking changes against the too verbose everything and their uncle changelog, peti also talked about it week ago and gave Pandoc as an example of too-too verbose Changelog.

Of course, I would do it through PRs, so we can review it.

[sjakobi]

Repl.hs is not a module exposed, so 0.8.1 then.

Note that we removed some exposed instances from Nix.Standard, as I tried to point out in #599 (comment).

What is hard in Changelog? With the right lazy verbosity of it.

In reality, people care and should be informed only about breaking changes in Changelog.

I think it's also nice to get some info on other user-facing changes, like additions.

Some changelogs take it a bit far and also contain less interesting stuff, like who made which documentation improvements, though. No need to imitate that IMHO.

[Anton-Latukha]

Yes, I just re-re-reviewed the diff. Slipped pass those, and then seen that in Repl.hs no instances, and understood that missed something. It is 0.9.0 indeed.

Yes, 0.0.x.0 are largely non-breaking additions - so that also can be changelogged.

[Anton-Latukha]

We together made a 0.9.0: https://hackage.haskell.org/package/hnix 🥳

Thank you, especially @sjakobi @sorki.

GHC 8.10: https://matrix.hackage.haskell.org/#/package/hnix 🥇

Now project has quite good build matrix. And docs. A proper Haskell citizen now 😃

[Anton-Latukha]

Next thread: #628