- Meeting Cadence:
- add me to the meetings
- where is work tracked
- how is work tracked
-

## Motivation ("The Why")

- Consolidate comms & desired feature-set for next version of the `npm` CLI (ie. `v8`)
- We are approaching the `node@16` ["Active LTS" Release](https://nodejs.org/en/about/releases/) milestone & want to make some decisions quickly
- In this next release our team has expressed an interest to...
- minimize breaking changes
- increase supportability while decreasing our maintenance burden
- align more closely with `node`'s release cadence & versioning (ex. keeping odd numbers as more experimental)

### How

- `npm@8` drops support for `node<12`
- `npm@8` will refuse to install in node versions it doesn't work with

### Dropping `node<12`

Today, we have rather a lot of workarounds for node 10 to keep things working. Part of this step will involve actively seeking those workarounds and removing them.

This will reduce the overall volume of code we maintain, and allow for simplifying things in other places.

### Refuse to install in old `node` versions

A lesson we learned with the release of `npm@7` is that we need to be more careful about how we interact with versions of `node` we don't work on. Quite a few folks had problems caused by `npm@6` allowing `npm@7` to be installed in `node@8`, this is something we intend to resolve.

Actively refusing to install an `npm` version that does not work with the user's current version of `node` will help reduce confusion and frustration for our users, as well as reducing support requests. With clear messaging, we can also encourage users to keep their `node` versions up to date.