drop old node tests, add node 16 tests, bump engines in package.json

[HonkingGoose]

Changes:

• Drop Node 0.12.x, 4.x, 6.x, 8.x tests
• Bump engines to >=12.0.0
• Add Node 16 tests

Context:

Closes #151.

[HonkingGoose]

According to the Semantic Versioning 2.0.0 spec (https://semver.org/):

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.

I'd say dropping Node versions is a "incompatible API change", and should probably get a new major release.
But I'll let the maintainers decide on what to do with the version number for the next release. 😄 😉

---

Or maybe you should follow this instead:

How should I handle deprecating functionality?

Deprecating existing functionality is a normal part of software development and is often required to make forward progress. When you deprecate part of your public API, you should do two things: (1) update your documentation to let users know about the change, (2) issue a new minor release with the deprecation in place. Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.

https://semver.org/#how-should-i-handle-deprecating-functionality

[piranna]

+1 on this. Maybe we can also review other open PRs and merge all them before releasing a 2.0.0, how do you see it all?

[HonkingGoose]

Maybe we can also review other open PRs and merge all them before releasing a 2.0.0, how do you see it all?

How do you like this process? It's basically "update all the things" for a new shiny 2.0.0 release.

1. Review, tinker, merge this PR (drop old node tests, bump engines in package.json) so that you have meaningful tests again.
2. Review, and tinker with the Dependabot configuration PR until you're happy (Create dependabot configuration #150).
3. Merge Dependabot config PR.
4. Use Dependabot dependency update PRs to update dependencies (leave updates with test failures for a later time).
5. Merge master into the other PRs to re-run the test suite on them.
6. Evaluate/review other PRs and merge them if needed/wanted, or close them if not wanted.
7. Release a new major version with a nice change-log of things that were added/removed/changed.

But I think that you as maintainers should decide how you want to handle this, maybe this is too risky to do for a major new release, and you want to keep (potential) breaking changes limited to just the Node version bump.