Old path is not existent, since `dist-newstyle` is used, path is ugly to
construct, so far settling for `cabal v2-run` autolocating `hnix`, thou the
problem is that Nix-env has GHC 8.8.3, and HNix binary builds only under
GHC >= 8.10.
M main/Main.hs
M main/Repl.hs
M src/Nix/Builtins.hs
M src/Nix/Convert.hs
M src/Nix/Effects.hs
M src/Nix/Effects/Basic.hs
M src/Nix/Eval.hs
M src/Nix/Exec.hs
M src/Nix/Expr/Types.hs
M src/Nix/Json.hs
M src/Nix/Lint.hs
M src/Nix/Normal.hs
M src/Nix/Options/Parser.hs
M src/Nix/Parser.hs
M src/Nix/Scope.hs
M src/Nix/String.hs
M src/Nix/TH.hs
M src/Nix/Thunk/Basic.hs
M src/Nix/Utils.hs
M src/Nix/Value.hs
M src/Nix/Value/Equal.hs
M src/Nix/XML.hs
M tests/EvalTests.hs
M tests/Main.hs
M tests/NixLanguageTests.hs
M tests/ParserTests.hs
M tests/TestCommon.hs
M Setup.hs
M main/Repl.hs
M src/Nix/Builtins.hs
M src/Nix/Cache.hs
M src/Nix/Cited.hs
M src/Nix/Cited/Basic.hs
M src/Nix/Convert.hs
M src/Nix/Exec.hs
M src/Nix/Expr/Types.hs
M src/Nix/Expr/Types/Annotated.hs
M src/Nix/Lint.hs
M src/Nix/Normal.hs
M src/Nix/Pretty.hs
M src/Nix/Render/Frame.hs
M src/Nix/Scope.hs
M src/Nix/TH.hs
M src/Nix/Thunk.hs
M src/Nix/Thunk/Basic.hs
M src/Nix/Utils.hs
M src/Nix/Value.hs
M src/Nix/Value/Equal.hs
* "Misc" use was disputed, moving back to use of the "Additional" category.
* Using a (link) pattern for URLs, reasons being:
* Including the markup into the outlines or hyperlinks considered a
bad practice and should be used carefully.
* The human cause:
The reason for the changelog is so people read through it and get the info.
Hyperlinks make text colored. Studies of readability have shown that
people perceive the information of a brightly colored text
much more poorly than the text of regular coloring.
And delivering the meaning is what changelog text is for, so the
informative text should be regularly colored.
* The technical cause -
the Hackage does not parse the markup inside the hyperlinks:
https://hackage.haskell.org/package/hnix-0.10.0/changelog
Probably because of the reason *1, but Hackage reason alone is enough.
* Since people perceive and think about the read information mostly linearly
and in the FIFO manner, `(link)` is put before information text, so links
are placed in the same space and look more uniform upon reading. And upon
reading the "link" context gets pushed first from the FIFO mind buffer and
the further understanding the text the person is not distracted by
sudden reading (taking-in) of the colored word "link" in the end of the
semantically challenging text that is required to be understood.
* Dependency requirements of last major versions made literal.
* Link to `(diff)` made more obvious. While professionals tend to look for the
link to the full diff, diff under version number is ambiguous to where the
version number link leads, it can be for example: a GitHub release (where
different forms of packages are provided), diff, commit listing (as it was before
the current change), official forum post, official news... etc.
* Made `(diff)` link to point directly towards the diff.
Option for debugging and bugreporting purposes.
Current output:
```
Version: 0.9.1
Commit: 2dc211314e
date: Sat Sep 12 13:31:59 2020 +0300
branch: 2020-09-12-add-GitRev-to-version
```
Also date and branch is to direct contributors attention to updating (or having
in mind) that.
M hnix.cabal
M src/Nix/Options/Parser.hs
* Prepare release 0.9.2
* CHANGELOG: m upd to 0.9.{2,1}
* Update changelog and version
* CHANGELOG: m upd: unification of structure, forming 0.10.1
Breaking changes into "Breaking" section.
Miscellaneous changes into "Misc" section.
Co-authored-by: Simon Jakobi <simon.jakobi@gmail.com>
Due to number of frequently occuring issues, latest being
the #705, #706, #707, #708, #709,
and upstream Nixpkgs issues, pinning Nixpkgs for Nix Haskell dev env.
* Remove all additional optional informative CI Nix builds, preferring following Hackage currently, and keep Nix dev narrow.
* Add Cabal Hackage builds for all GHCs HNix supports.
* Rename Nix workflows to direct literal meaning of what they are (`Nix-dev-env`).
* Created a release test for middle GHC versions. CI tests always the latest and the oldest version, that seems good enough to track the development process. The middle GHC versions get tested when someone creates a GitHub prerelease/release.
