There are archives of MC Knowledgebase, which google will find, I don't
want to try to keep a link to an archive working since MS is no longer
providing it.
This reverts commit b5dc04099e.
Broke windows build, because the new lts updates Win32 to a version that
lacks a function that git-annex needs. git-annex.cabal depends on an
older Win32, and so stack build fails.
Will need to wait to update stack.yaml until this is fixed
https://github.com/haskell/win32/issues/208
and is in a new LTS release.
This has not been needed since stack <1.4.0, and even the i386ancent
build uses stack 2.1.1.
Stack 2.7.5 seems to have forgotten about this old config and warns
about it, so this avoids that warning.
The libtinfo-dev was added to the docs at the same time, I assume it is
also not necessary.
Last try at this broke on windows with a problem installing ghc, but I
wanted to try again.
Also this has a version of aws that allows using aeson 2.0, which has a
potential security fix.
There is nothing in upgrade.log because it was never upgraded to version
9. Before, it would have never autoupgraded to 10, but it's entirely
safe to upgrade to 10 immediately.
Of course, annex.autoupgraderepository = false will prevent that
upgrade. So if someone for some reason really wants v9, they can set
that. I can't think of a reason someone would actually want v9 rather
than v10 though.
Sponsored-by: k0ld on Patreon
(And v9 later on to v10.)
When v9/v10 were added, making v8 automatically upgrade was deferred
"for a few months" to prevent interoperability problems if users also
have an old version of git-annex. Of course that could still be the
case, but there has been a good amount of time and this can't be put off
forever.
Allow setting annex.autoupgraderepository to false to avoid this upgrade.
Previously, that only prevented upgrades from no longer supported git-annex
versions, but v8 is still supported, and users may want to keep on v8 to
interoperate with an old git-annex version.
Sponsored-by: Boyd Stephen Smith Jr. on Patreon
With automatic upgrades to v10 enabled, this could have led to each
run of git-annex adding a line to upgrade.log for v9. However,
they're not yet, so it only happened when running git-annex upgrade
in a v9 repository.
Sponsored-by: Brock Spratlen on Patreon
This would have prevented old git-annex from ever upgrading from v9 to
v10. Note that a manual `git-annex upgrade` can never run while the
assistant is running, so not <$> assistantrunning was always True,
so no matter what the timestamp of the v9 upgrade in the log, it would
decide there was old process danger.
Sponsored-by: Jack Hill on Patreon