Do we need the RC release?

[RyanCavanaugh]

Our current release schedule is as follows:

• Every night, publish a nightly from the dev branch
• Publish a "feature-complete" beta from the dev branch roughly halfway through each milestone
• Publish a "presumed-ready" RC (release candidate) two weeks before the final release. At this point, main becomes the new dev branch, and the release branch becomes terminal and new features can ship in the nightly
• Publish a "ready" final release. Critical bug fixes from now on are merged into both main and release-X.Y branches
• Publish as many patches as needed to fix critical issues found in the final release

A recent discussion made us question whether the RC release provides sufficient value to justify its place in the release cadence.

Arguments in favor of removing the RC:

• Anecdotally, we don't get a spike in bug reports during the RC period, but do during final releases, bad nightlies, and betas. This would indicate that not many people are really kicking the tires on the RC
• The RC period creates an awkward timeframe wherein bug fixes need to be merged into multiple branches
• Anyone who wants a pre-release version can just as easily pick up a nightly, including a nightly build corresponding to two weeks prior to the release, and people do so
• Effectively no one must upgrade their TypeScript version immediately; so anyone who wants a more-stable release can equally wait for two weeks (or more!) after any given release to wait for any last bugs to get ironed out

Arguments in favor of keeping the RC:

• This creates a clear "you can't say you couldn't have tried it" window for people who want to stably upgrade ASAP
• Ceteris paribus, the RC lets us ship new features in nightly two weeks earlier
• If even a small number of people try it, this does reduce the number and size of patch releases

Are we missing anything? Is the RC critical to your workflow in ways we're unaware of?

[DanielRosenwasser]

The RC period creates an awkward timeframe wherein bug fixes need to be merged into multiple branches

Can you explain how removing the RC release itself alleviates this? Are you saying that if we removed the RC, bug fixes for TypeScript X.Y would just continue until the stable release date?

[RyanCavanaugh]

Up for discussion, but I'd sort of presume a small "no risky fixes please" window prior to the final release, the same way we have that policy loosely enforced for risky fixes prior to the RC branch cut.

[DanielRosenwasser]

I think there's a tension for the core team to think about between

the RC lets us ship new features in nightly two weeks earlier

and

The RC period creates an awkward timeframe wherein bug fixes need to be merged into multiple branches

If you want to get rid of the second one, you sacrifice the benefits of the first.

But I'm more curious to hear about external usage of the RC and if anyone plans around it.

[nopeless]

I am just mentioning this because it is not explicitly mentioned in the original post

Have your team considered a longer RC period? It could be that the 2 week timeframe is too short for developers to notice and try out the new features.

[koshic]

With current stability & toolchain compatibility level (it's not an evaluation, just an observation) RC is useless for me & my team. Why? Because any feature can be changed in any way before release. So there is no reason to prefer RC over nightly.

[fatcerberus]

It was my understanding that policy is for no breaking changes to be made after beta, barring extenuating circumstances (e.g. reverting changes that already broke code in the wild).

[kitsonk]

We (@denoland) tend to do an integration PR for the RC and the beta. Mostly it stops at the point of just looking for any changes or regressions. It usually isn't until the point of upgrading to the release that we really focus on any new features (or even after the release).

I can't think of a time in the past few years though where we have identified an issue that then was an TypeScript change or bug fix, just usually a few minor updates to some of our built-in types or other minor tweaks.

[DanielRosenwasser]

To that point, the RC gets published via GitHub, and I know that's usually how you try it out. Is that a hard requirement?

[kitsonk]

We stopped doing that in our workflow, as we felt bad about bagging to get the git tag pushed. We now just install it locally via the npm tags.

If you are bored and want a dry read, here are the full details: https://github.com/denoland/deno/blob/main/tools/update_typescript.md

[jakebailey]

If you are bored and want a dry read, here are the full details:

Thanks for linking this! Unrelated to this thread, but in #51026 I (re-)discovered those "dead" files your instructions mention; we've totally been shipping now-deleted lib.d.ts files and not realizing it. (Well, I presume so, it could be that we keep these around for a reason.)

[robpalme]

Thanks for opening up the question. I enjoyed learning that "Ceteris paribus" means "All else being equal".

TypeScript Users' Perspective

Our current in-house practice is to perform thorough testing of Beta releases, followed by a period of intense testing of nightlies until the RC occurs. Once the RC happens, proactive fixes are applied to the entire codebase to ensure it is compliant with the existing and next version of TypeScript. Once Final Release happens, we'll usually wait about a week before integrating it into our toolchain just in case any urgent patch releases occur. Lastly, that toolchain containing the new TypeScript release is made available to all internal developers.

The main reason for beginning testing at the point of the Beta release is in order to feedback information (via issues on this repo) that might lead to a reduction of breaking changes in the Final release.

The reason for using the nightlies between Beta and RC is because we historically found breaking changes were both removed and (crucially) introduced between the Beta and RC, whereas post-RC there is a much higher degree of stability. So from this user-perceived point of view, the RC is valuable as a point at which we can reduce daily monitoring effort and make a concrete plan (with a mostly understood time estimate) for the work needed to upgrade the codebase to comply with the set of compatibility breaks that will be delivered in the Final release. In some cases, this "RC release" signal gives sufficient notice period to ensure that the codebase is already compliant on the day of the Final release.

Therefore, even if the RC was retired, from a heavy user's point of view, it would still be useful to have a defined point/signal after the Beta but before the Final release at which there is a widely-understood declaration of stability, i.e. essential bug fixes only. In the absence of an explicit signal, the Final release would become that signal by default, and the consequence would be a ~2 week delay in our adoption of Final releases.

TypeScript Implementer's Perspective

I think the question of "Do we need an RC?" stems from the more foundational classic question of what to do when you approach a release date and need stability: feature-freeze or branch?

• Freeze: For a given time frame (e.g. two weeks) impose a stricter policy on the type of PR that can be merged to main, e.g. essential fixes only.
• Branch: Create a release branch that accepts essential fixes only, so that regular development can continue on main

The OP already lists the trade-offs. Personally I would prefer branching because the stability intent is reflected concretely as a structure in Git. It makes the policy more "real" and visible to all.

[RyanCavanaugh]

Everyone is welcome for the impromptu Latin lesson

We've heard some offline feedback quite similar to @robpalme's, so it seems like enough people are getting use out of the RC that we can keep it.