Lock minor version for plugins

[haoqunjiang]

What problem does this feature solve?

Consider our current version strategy:

• A patch version may include the following changes:
  • Fixes for regressions introduced in previous versions
  • Fixes for buggy behaviors (of the binary, config or generator)
• A minor version may include the following changes:
  • New command-line options
  • Generator template changes
    • Most of the time, even if the new template is completely different from the old one, it's still considered a semver-non-breaking change because it does not affect existing users' projects
    • This gives us the flexibility to upgrade a major version of an underlying dependency without bumping Vue CLI's version too aggressively (e.g., we can ship ESLint 5/6 support in a minor release)

---

But this strategy has its drawbacks.

First, in patch versions, the two types of fixes are not of equal importance:

• For regressions, they should be fixed as soon as possible because they're unexpected behaviors for all users
• For a buggy behavior, if exists for too long a time, it may be treated as a feature by some users. So fixing such a bug may be a breaking change for them

Secondly, for generator template changes, though they don't affect existing projects, we, on the other hand, don't have a convenient way to inform users to upgrade their projects' settings. This could become a huge maintenance burden in the long run.
One way to mitigate this issue is to utilize the vue upgrade command and write Migrators. But with current version strategy, people don't often realize its existence unless they're upgrading to a new major version, as npm automatically installs the latest minor versions even if they don't manually update the version ranges in package.json.

So here I'm proposing a new versioning strategy for Vue CLI plugins.

What does the proposed API look like?

• In the generated project, the version range of the CLI plugins should start with a tilde (~) instead of the current caret (^)
  • It's recommended to periodically vue upgrade in the projects to check for new versions and try automatic migrations;
  • Other third-party peer dependencies are not bound to this versioning strategy because they might have their own concerns on release plans. It's better to be evaluated case by case. For example, we need to use ~ for the TypeScript version, while the ESLint version can start with ^.
• Patch versions should only include fixes for regressions and security vulnerabilities. All other non-significant bug fixes should be postponed to the next minor release.

[pksunkara]

Secondly, for generator template changes, though they don't affect existing projects, we, on the other hand, don't have a convenient way to inform users to upgrade their projects' settings. This could become a huge maintenance burden in the long run.

Shouldn't this be divided into 2 different scenarios? One where we don't need to upgrade users' projects' settings and the other where we need to.

For example, I have a PR where I am adding an option to our router plugin which completely changes how it's run but the users' projects' settings won't be effected. It's not they are going to run the initial setup again.

I think, for even vue-cli plugins, we might need to do a case by case regarding ~ and ^.

[haoqunjiang]

One where we don't need to upgrade users' projects' settings and the other where we need to.

But in the long run, we want users to always use the latest setup. It makes a plugin author's life easier.
And they might never notice such changes during minor version updates if we don't try harder to inform them.

So what I proposed here is that we'd keep a ~ version range and encourage users to check for updates periodically. Because it's only minor version updates, the process should be quite smooth and without much burden.

It also makes auto migrations easier:

1. Currently vue upgrade is only used for major version upgrades but in a major release, there're always some changes that can't be automated away, so it doesn't do enough help as we expected. But if it's used in a minor version update then the migrator can be of greater help IMO.
2. One problem in the current implementation is that we can't easily determine which version the user's from.
   For example, a user specifies @vue/cli-plugin-typescript@^3.5.0 in their project but the actual installation is of v3.12.1 because of semver, and they might have manually changed their folder structure according to the release notes of v3.7.0 or some other version.
   When we want to programmatically update the project files, we can't even make a reasonable assumption about the project setup based on their specified or installed plugin version. This makes a migration script very hard to write.
   Such issues can be mitigated with a ~ version range.

In my opinion, as long as generator template changes are considered as semver minor, we'll eventually need such a mechanism in some future updates, so it's better to plan early.