Versioning

[littledan]

The explainer in this repository has version numbers. The Web, ~~Node~~ and JS built-ins are generally unversioned, so far. What are the advantages and disadvantages of versioning? How should it apply to the standard library?

[mcollina]

Node.js built-ins have a version number, the version of Node.js itself. We have done semver-major changes to those in the past.

[littledan]

@mcollina Thanks, I wasn't aware.

[devsnek]

I'd be in favor of not having explicit versions. The current process for developing the spec is very rigorous, and the system it uses for introducing changes makes a lot of sense for consumers of js.

[chicoxyzzy]

I'd prefer to have versions because breaking changes are really useful sometimes. Having versions of std could fix JS in many ways

[jhpratt]

I'm of the opinion that specifying a major version should be required. This would minimize potential breakage when breaking changes are released. Minor versions only add new features, so that wouldn't be an issue.

(I'm working on the assumption semver would be used at some level)

[obedm503]

Assuming that standard library packages are built-in to the browser environment, is it practical to expect browser vendors to have multiple versions of each package?

Say a website today uses [email protected] package, but in 10 years other websites use [email protected], are the browsers expected to have and support all versions? ("Don't break the web" will still be a thing)

If ecmascript itself had versions, I would say yes, the standard library should be versioned along with it; like what node already does. But it doesn't.

I do hope I'm wrong and a way is found to version the standard library, but that seems inconsistent with the rest of native js.

[littledan]

I think one of JS and the Web's biggest values is that they are unversioned: We strongly avoid breaking changes. People can be confident that their application will keep working in the future. API changes are done through gradual evolution, or occasionally, making a new parallel API that is richer. Programmers can gradually take advantage of new features rather than take a big bump at some point. I'd like to keep this pattern of evolution, and leave things that will need versioning to non-built-in JavaScript modules.

[fregante]

Breaking changes might be necessary sometimes, but they're not that frequent and there's already a way to handle them:

• Date needs a breaking change, therefore Temporal is being proposed
• isNaN needed a breaking change, so Math.isNaN was introduced

This is not super flexible, but it's not like APIs are updated that frequently.

[victornpb]

Breaking changes might be necessary sometimes, but they're not that frequent and there's already a way to handle them:

• Date needs a breaking change, therefore Temporal is being proposed
• isNaN needed a breaking change, so Math.isNaN was introduced

This is not super flexible, but it's not like APIs are updated that frequently.

Mistakes accumulate, so the bad footprint only grows over time. But i think i agree with @littledan, even tho I was supporting versioning, this encourages vendors to drop versions at some point, and I already foresee a future where they only want to keep 2 versions and they are only a couple years old, and that would mean a site a few years old can become not supported.

Every MacOS update which happens every year, I have to delete at least a couple Apps that stop working because Apple removes APIs, and some will never be update, becoming a useless blob of bytes.