Defining a process/timeline around major language/platform/framework updates

[kfcampbell]

The recent .NET 7 release got me thinking about appropriate timelines for major releases to our languages/platforms/frameworks. In the past, we haven't had the capacity to define and implement a procedure/timeline for such updates. Perhaps it's worth doing so now.

A few related questions, in no particular order:

• What do we define as a major release? (e.g. will any library's breaking changes cut it, or are we sticking specifically to language runtime and module ecosystems?)
• How long after general availability should Octokit adopt updates?
• What should our review process/acceptance testing procedure be?
• Will the deprecation schedule of old versions be linked to adopting new versions?
• How many current versions of any language/platform/framework will we support at any given time?
• WIll the answers to any of the above change by language/SDK?

[kfcampbell]

In the interest of promoting conversation, I'm going to offer what I think would be reasonable answers to the above questions:

What do we define as a major release? (e.g. will any library's breaking changes cut it, or are we sticking specifically to language runtime and module ecosystems?)

We should stick specifically to language runtime and module ecosystems. If .NET 8 is released, we should count that. If Microsoft.NET.Test.Sdk gets a new major version, that shouldn't count.

How long after general availability should Octokit adopt updates?

Ideally, this should be as soon as possible; perhaps we shoot for within a month after release? However, the answer might have to be language-dependent: in Go for example, backwards compatibility is highly prioritized and the community tends to update quickly. In other languages, this may not be true.

What should our review process/acceptance testing procedure be?

We should add the new version to any relevant build/test matrices at a minimum. I'm currently blanking on what other appropriate next steps might be.

Will the deprecation schedule of old versions be linked to adopting new versions?

I'm torn about this. Perhaps it should depend on usage: we could check developer surveys to see when a critical mass moves to the new version. Alternately, we could mirror language support from the language maintainers.

How many current versions of any language/platform/framework will we support at any given time?

For this, we should likely mirror the support process from the maintainers.

WIll the answers to any of the above change by language/SDK?

Yes.

[gr2m]

I'm not sure how/if these questions apply to the JavaScript ecosystem as it does for .NET? For JavaScript, maybe the most relevant releases are currently Node.js. As soon as a new Node.js version comes out, we should add it to our test matrix. But if I recall correctly there was never a breaking change with a newly introduce Node.js version.

When a Node.js version gets out of maintenance, we should simply remove it from our testing matrix.

Node.js has a pretty reliable release schedule: https://github.com/nodejs/Release#release-schedule

[G-Rath]

I'm not too sure how it works in .NET land, but generally I vote for a "if its not broken..." approach - unless there is an actual good reason to stop supporting a version of Node, I think we should continue supporting it until such a time that we have a good reason.

Such reasons could include that a significant number or versions of dependencies are not compatible with an old version of Node (though not just because they've moved to ESM - more like if the version we're using has security issues, or there's a significant performance gain, size reduction, etc), the cost of transpiling has grown to be noticable (since currently stuff like optional chaining tends to be very low-cost), or just because it's been so long that that version is super painful to try and use and maintain etc.