Repository navigation
Do we need the RC release? #50999
Description
Activity
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?
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.
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.
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.
Reacted by Daniel RosenwasserWith 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.
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).We (Deno (@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.
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?
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
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.)
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
releasebranch that accepts essential fixes only, so that regular development can continue onmain
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.
Reacted by Titian Cernicova-Dragomir and Ryan Cavanaugh- Freeze: For a given time frame (e.g. two weeks) impose a stricter policy on the type of PR that can be merged to
Everyone is welcome for the impromptu Latin lesson
We've heard some offline feedback quite similar to Rob Palmer (@robpalme)'s, so it seems like enough people are getting use out of the RC that we can keep it.
Our current release schedule is as follows:
mainbecomes the new dev branch, and thereleasebranch becomes terminal and new features can ship in the nightlymainandrelease-X.YbranchesA 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:
Arguments in favor of keeping the RC:
Are we missing anything? Is the RC critical to your workflow in ways we're unaware of?