Clarify what is a minor version

[yoavweiss]

After sending an intent to ship for this, we got feedback that the minor version is needed for polyfilling for Safari.

At the same time, I don't think the intent of minor version in the spec was to include Safari's mid-year releases as "minor", since they include many new features.

We need to clarify that "minor" means a bug fix release with no major features.

[domenic]

I would suggest then changing the terminology; "minor version" is often taken to specifically mean versions which change the second component after the dot. (I.e. there's the trio major.minor.patch.)

[jridgewell]

Maybe use "significant" browser version?

For Chrome and Firefox which ships major versions every few weeks, the only significant part of the version is the major (eg, Chrome-81). But for Safari which ships majors once a year and minors throughout the year, the major and minor are significant (eg, Safari-13.1)

[yoavweiss]

I'm fine with "significant". What should we call the other ones? "bug fix releases"?

[JakeChampion]

It sounds like this proposal will also be setting up strict rules for how any browser (including new ones like Flow Browser) for how they are meant to version themselves. Is this proposal defining the rules to be something similar to the SemVer 2 specification?

[yoavweiss]

This is waaay out of scope. Seems like moving away from "major" and "minor" should clarify that

[jridgewell]

I'm fine with "significant". What should we call the other ones? "bug fix releases"?

Is "insignificant" not enough? I would really want to call them "minor releases", but "minor" is exactly the terminology we're trying to avoid. Thesaurus gives:

• small
• unimportant
• insignificant
• inconsequential
• inconsiderable
• negligible
• trivial
• lesser

Any seems ok, even "bug fix releases".

[yoavweiss]

"insignificant" (or any of the equivalents) seems to belittle those minor releases, which may well have critical bug fixes.
What do y'all think of "feature" release vs. "bug fix" release?

[jridgewell]

Sure, though I think "significant" is better. But anything that gets away from the semver terms is good.

[JakeChampion]

@yoavweiss do we define what "feature" and "bug fix" mean? If a release fixes turns a spec non-compliant feature into a spec-compliant feature, is that considered a "bug fix" or a "feature?

[yoavweiss]

I think this is something that product teams of the different browsers would have to decide for themselves.

[foolip]

If we go with the assumption that Safari will keep going with their version scheme, then I think the most conservative path here for future interop is to require two components to the version, even if that means "79.0" for Chrome. The reason is that otherwise it will be possible to parse some version strings as integers, and if most browsers have only a major version, people might do that and realize only in production that it's broken in Safari.

[yoavweiss]

Removed the "major"/"minor" wording from the spec. I think we can go with "version" for the major version and "full version" for a hint that would include major and minor. See #11 (comment)

[yoavweiss]

If we go with the assumption that Safari will keep going with their version scheme, then I think the most conservative path here for future interop is to require two components to the version, even if that means "79.0" for Chrome. The reason is that otherwise it will be possible to parse some version strings as integers, and if most browsers have only a major version, people might do that and realize only in production that it's broken in Safari.

@foolip - I don't want to assume specific browser version structures here. Browsers know which of their versions are feature versions and which are bugfix only, and can set those values accordingly.

[yoavweiss]

Closed by #46 which did a s/major/significant/g