Prepare 1.0.0 release

[Ailrun]

As mentioned in #1310 (comment), we consider releasing the major 1 version of HLS (and maybe plugins?)
This PR currently bumps only HLS, but if we decide to do so, I will bump other plugins too.

Now this PR bumps all versions including GHCIDE.

[wz1000]

I support this move. I think we should also use this opportunity to start strictly adhering to PVP (https://pvp.haskell.org/) in an attempt to solve the problems we are facing with plugin bounds.

In particular, this would involve putting upper bounds on the ghcide and hls-plugin-api dependencies of the plugins, and as well as adhering to PVP in the ghcide and hls-plugin-api versions, which means that breaking changes to the API versions of either necessitate a major version bump. If a plugin is compatible with a major version bump in one of these packages, it should be indicated with a hackage revision.

[pepeiborra]

ghcide and hls-plugin-api have failed to adhere to the PVP in the past. Mea culpa, unintentionally. Hopefully it can be avoided in the future. Some automation would help!
Can we have:

1. A CI check that will fail if a version update is not compliant, e.g. a minor version bump with breaking API changes
2. A post-commit hook that uploads new releases to Hackage whenever a version bump has happened.

[wz1000]

@fendor suggested https://github.com/kowainik/policeman/ to check PVP compliance.

[fendor]

In issue #1403, a bug with latest hie-bios has been uncovered. I am fixing it in haskell/hie-bios#283 but would ask to wait with this release until next hie-bios version has been released (which should be in the next half hour or so)

[Ailrun]

OK, let's wait till that fix is released & introduced into HLS.

[fendor]

hie-bios release is uploaded to hackage: https://hackage.haskell.org/package/hie-bios

EDIT: can't provide a PR, since the pre-commit hook blocks me for some reason. Managed to commit by deleting the pre-commit hook :)

[jneira]

The Changelog looks really, really nice, many thanks.
I think we should bump up all package versions, inclufing ghcide, hls-plugin-api and plugins to 1.0 in this pr, if it is not asking for too much.

Afaics there are two alternatives to manage versions:

• Set all packages to the same version now and bump up the minor version of all of them at once, always, following pvp in a trivial way (from @michaelpj and @ndmitchell comments here and here, i hope i've understood it correctly)
• Follow pvp strictly as suggested by @wz1000 above

Usually i am inclined to follow pvp, but i have to recognize that the first one is very simple, dont even need automation and you identify the release in a quick look for any package.

[jneira]

The Changelog is perfect.

However, i would bump up plugins before the release (whatever way we choose), to not have to do a branch 1.0.0-hackage and cherry-pick changes in cabal files (it caused problems last time)

[berberman]

In addition, I think it's time to update nixpkgs to ghc 8.10.4, like 8de2ca5 did

[pepeiborra]

The Changelog looks really, really nice, many thanks.
I think we should bump up all package versions, inclufing ghcide, hls-plugin-api and plugins to 1.0 in this pr, if it is not asking for too much.

Afaics there are two alternatives to manage versions:

• Set all packages to the same version now and bump up the minor version of all of them at once, always, following pvp in a trivial way (from @michaelpj and @ndmitchell comments here and here, i hope i've understood it correctly)
• Follow pvp strictly as suggested by @wz1000 above

Usually i am inclined to follow pvp, but i have to recognize that the first one is very simple, dont even need automation and you identify the release in a quick look for any package.

The 1.0 proposal simplifies things, but because there may be ghcide and plugin releases in between big HLS releases, you also need both fixed bounds (== 1.0.*) in all build depends entries, and PVP adherence.

Moreover, we still need to address the coordination problem of uploading all plugins to Hackage.

[jneira]

If we are gonna do hackage releases of subpackages between monthly releases we would need 1.0.* for sure.
We still could do a total 1.1 the next one (or dont, we will see).

So what about bump up all packages to 1.0 and all bounds to 1.0.* right now?

[jneira]

Maybe we should mention that new hie-bios use a dedicated build dir for cabal so it would fix the continual rebuilds: https://github.com/mpickering/hie-bios/blob/master/ChangeLog.md#2021-01-29---073

[jneira]

lgtm, thanks for your thorough work 🙂