feat: more sensible counter and version color

[a1mersnow]

It's important to determine what major,minor,patch mean.

Case 1: If major refers to the change of x of x.y.z(this is what semver.diff use):

	change type
0.3.4 -> 0.3.7	patch
0.3.4 -> 0.4.6	minor
0.0.3 -> 0.0.4	patch

Note: semver.diff has other types: premajor, preminor, prepatch, prerelease, e.g.:

Case 2: If major refers to "break the ^"(this is what changeVersionRange use):

	change type
0.3.4 -> 0.3.7	patch
0.3.4 -> 0.4.6	major
0.0.3 -> 0.0.4	major

Note: ^ simply means allowing changes that do not modify the left-most non-zero version number.

Case 3: If major refers to "any change below 1.0.0"(this is what colorizeVersionDiff use):

	change type
0.3.4 -> 0.3.7	major
0.3.4 -> 0.4.6	major
0.0.3 -> 0.0.4	major

colorizeVersionDiff:

export function colorizeVersionDiff(from: string, to: string, hightlightRange = true) {
  // ...
  // major = red (or any change before 1.0.0)
  // minor = cyan
  // patch = green
  const color = (i === 0 || partsToColor[0] === '0')
    ? 'red'
    : i === 1
      ? 'cyan'
      : 'green'
  // ...

Which one is more sensible?

Solution

From the aspect of user, when I run taze major, I'm saying I can accept breaking change,
when I run taze minor, I'm saying I cannot accept breaking change but I want more features, when I run taze patch, I'm saying I want only fixes.

The first one I want to eliminate is Case 1. At first, it's not a thing users care much. Secondly, the design of npm-semver's ReleaseType has many pitfalls, as to cause many issues about it.

Case 3 is a safer one. It's always good to use a safer one but it's a little bit conservative. And, I don't think it's a good idea to change the meanings of today's mode, but it's ok to change only the UI part.

So, this pr picks the Case 2.

[antfu]

Making sense, thanks for the PR and detailed explaintation!