Does a date-based versioning scheme make sense?

[ryanoglesby08]

I chose to go with a date based versioning scheme instead of semantic versioning, because it seems that SemVer doesn't make as much sense in this context. Is a change to the browser list a major, minor, or patch?

The optimal way I see this being used would be that the browsers list is occasionally updated based on new analytics data, and then a new version of this package is released. That new version is now tied to the time at which the data was collected.

So, I set the version to 2018.04 to represent the list of supported browsers as of "April 2018". This is an implementation of CalVer. Let's say the list is updated in October, you would bump the version to 2018.10.

I'm not sure how npm/yarn handles dependencies that do not use SemVer though. I guess apps would want to pin to a specific version?

Thoughts? Does that make sense?

[ahmadnassri]

if we use GitHub releases the date problem is solvable as reference between semver and tag / release date?

[ryanoglesby08]

@ahmadnassri I'm not sure I follow. Do you mean to say that using SemVer is fine, as the date of the release is tied to the SemVer number?

In that case, I guess every release would be a major version bump?

One possible downside I suppose is that there is less information for teams on how stale their browserslist config is, and they have to go searching through Github to find out? Date-based conveys that the package is inherently tied to a specific point in time without needing more info.

"devDependencies": {
  "@telusdigital/browserslist-config": "2018.04"
}

// vs

"devDependencies": {
  "@telusdigital/browserslist-config": "2.0.0"
}

All that being said, it probably doesn't matter too much. I'm open for either.

[theetrain]

With Renovate in mind, I prefer semantic versioning over dates for these reasons:

• treating a calendar year as a major release means major version bumps can only occur in January, which may not be indicative of actual breaking changes as they may occur at any time during a given year
• assuming we have continuous insights on what percentile of browsers we support, the version can indicate when a browser is no longer supported, and Renovate can send PRs as they happen

I'm not 100% sure how to version the change in browser support. My thought is:

• major version for dropped support, such as no longer supporting IE11; which may result in a moderate refactor
• minor version for extending or reducing browser versions by a single increment
• patch version for ??
• or instead, use a single version number and treat every change as a breaking change

It's also worth mentioning we may need multiple support configs for different audience segments.

[ryanoglesby08]

It's also worth mentioning we may need multiple support configs for different audience segments.

See #1

[ryanoglesby08]

Re: versioning.

After doing some research into how npm handles versioning, it seems that npm strongly "encourages" all packages to follow semantic versioning and doesn't support anything else. So, trying to do CalVer doesn't make sense. Dropping that idea.

[ryanoglesby08]

@theetrain

I'm not 100% sure how to version the change in browser support.

I like the single version number, every change is breaking. Since multiple tools read this config and change build processes based on it, changing the supported browsers will have unknowable effects on dependents. It also depends on which version of the various tools dependents are using. Also, the other options don't really fit that well into semantic versioning, and I'd rather not try to shoehorn it.

My recommendation is to make every new package here a major version bump. e.g 1.0.0, 2.0.0, 3.0.0. A patch could be used if the previously published package is somehow corrupt, such as a missing comma or something.

[ahmadnassri]

added https://github.com/telusdigital/browserslist-config/commit/09fe5f14dccc7d05df134210ea300649b51b78b0 which will enable automatic releases in semver