add a 'v' to the version number in the meta-schema uri

[gregsdennis]

What kind of change does this PR introduce?

General update

Issue & Discussion References

None

Summary

I saw this in Slack in a conversation between @karenetheridge and @jdesrosiers. I'm not sure who came up with it, but I think it addresses @karenetheridge's concerns that the 1/2025 looks like a date.

Does this PR introduce a breaking change?

No. It's already broken.

[karenetheridge]

I can see some merits in releasing the next version as v1, implying that up until now the releases were not at the same level of stability, but I still don't understand the intent behind making a secondary number be the year. It (like our previous release numbers) artificially dates the release (draft2020-12 looks old simply because 2020 was five years ago), but also artificially places a limit on one release per year. If we wanted to do a second release within the same year, does that mean we'd be forced to increment the first component of the version, even if it otherwise did not merit it?

[gregsdennis]

I hear you @karenetheridge but given that we're struggling to output them over multiple years, I question our ability to output multiple in a given year.

Additionally, in the discussion for the release process, we decided that any changes will wait for the next publication, which will occur annually, meaning that we won't have multiple releases in a year.

It seems that the whole date convention was introduced on #612, but I can't find a fully compelling reason why we decided to go with that over numbers. The new convention of /v1/2026 simply carries that forward. I do think that the new convention actually attributes purpose to the year, though. You can have /v1/2027 and /v1/2028, both of which clearly indicate compatibility with previous releases, even though they're separate publications. Otherwise, we'd do something semver-ish, like OpenAPI does. I'm not particular attached to either way.

[jdesrosiers]

artificially places a limit on one release per year. If we wanted to do a second release within the same year, does that mean we'd be forced to increment the first component of the version, even if it otherwise did not merit it?

I don't know if you saw my response to this in the Slack thread. I think you're thinking about this from a traditional immutable spec perspective similar to what OpenAPI does. I think it will make sense when you shift to thinking about a living spec model.

(Here's what I wrote in that thread, because not everyone has access to it.)

Have re-read of the ADR we wrote for selecting a new spec development process. I think that will help remind why we chose annual releases. This blog post describing ECMAScript's move to the TC-39 process might be useful as well. Our process is inspired by TC-39 and I think the success of that process is good incentive to emulate it.

In short, it's a living spec that we can update at any time we want. So, we aren't limiting ourselves to making changes once a year. Not only can we make changes at any time, we encourage and expect implementers to make those changes as soon as they appear in the spec. The "releases" are just annual snapshots of where the spec is at that time. Implementations that say they support 2025 are asserting that they support everything in the spec as of that snapshot. They may also include things added after that snapshot and are even encouraged to include experimental and proposed features (probably behind a config flag) to vet those proposed features and generate the feedback we need to be confident in adding it to the spec.

Given that model, there's no need for arbitrary releases. A regular release schedule makes more sense.