Release cadence

[Kilian]

Since the last update with 38.0.0 and 39.0.0-alpha.1 two weeks ago there have been 10 official Electron releases. What is the expected release cadence for electron-releases?

[khwaaj]

We used to provide a build for each released Electron version for all supported release series. This was recently changed to instead do monthly releases in an effort to better manage the resources we have available for running this project, see the announcement in the News section of the Wiki:

https://github.com/castlabs/electron-releases/wiki#2025-07-15---announcing-reduction-in-ecs-build-frequency

[Kilian]

I see here that it's once a month: https://github.com/castlabs/electron-releases/wiki#2025-07-15---announcing-reduction-in-ecs-build-frequency

This part I found disheartening:

This effectively means that not every release of Electron will have a corresponding ECS release build produced.

While I can understand doing so for older releases, I'm of the opinion that it's important to keep parity for the current release to always make it possible for users to release a version of their app with the latest release, while having older major versions be updated on a needs basis.

[Kilian]

Please consider this input for the evaluation then.

I of course prefer the rolling release that you had since it meant having access to a current version at every point.

I understand the need to keep the effort maintainable and making less releases is one way to do that. However, Electron has a release cadence of a major version every two months. If electron-releases only updates once a month, that feels like too little to properly keep up.

A hybrid approach where electron-releases only updates older versions of electron under specific circumstances but keeps up to date with the current release would have my preference. On the other side: for the alphas and betas of the next version we can rely on the official betas instead. electron-releases could then only mirror the full releases of the current major version, which I hope could be equally manageable.

[khwaaj]

We will consider any feedback we are getting during the evaluation, so thank you for telling us your take on things.

We have not historically seen that there has been a quick uptake of the most recent release series, in fact it does not seem uncommon for users to linger on older versions for a while (in some cases to the point of falling out of the supported window). This was one of the reasons we chose to not make a distinction in cadence between the supported release series at this time. Unfortunately we don't really have proper metrics for this, so feedback that helps us get a wider/better picture is certainly appreciated.

[iamEvanYT]

A hybrid approach where electron-releases only updates older versions of electron under specific circumstances but keeps up to date with the current release would have my preference.

I agree with this too. Having at least one major version that keeps up with electron's changes quickly would really help as it would let us test changes as soon as they land. This being the latest major would also be the best option as it would have all the newest features + it is generally more supported in Electron too. It would also give people an option to upgrade to latest if they wanted the patches, instead of not having an option at all.

I also saw there was a discussion from quite a few years ago to merge the changes into electron upstream. Wouldn't that help reduce the resources needed to maintain this project? It would definitely eliminate the need to build every Electron release manually.

[Kilian]

As illustration: I am about to release a new version of my app running on 38, but there are pretty serious performance regressions on mac tahoe that have gotten fixed (just yesterday): https://github.com/electron/electron/releases/tag/v38.2.0 in all currently supported versions (36, 37, 38 and 39).

We're pretty close to a new release from you folks, but if this was released e.g. a week after your monthly release, that would be quite a long wait.

[ntoskrnl7]

I understand the slow uptake. However, when a critical Chrome security issue is discovered and patched, a month is too long. Security fixes should land within days, not weeks. Please consider a security-only fast channel or out-of-band patches with a clear SLA so organizations can adopt critical updates promptly.

[khwaaj]

There is actually a provision for high severity issues in the announcement, "Exceptions to this rule can be made for high severity issues, assuming we are made aware of them", which was meant to deal with such a situation.

So if the case is made for a specific release that fixes a severe security issue we will consider making an extra build available.

[Kilian]

Can you make available a set schedule for when new releases are made so we can plan around that? e.g. "each first monday of a month"

[khwaaj]

This is, and has always been, best effort, so we can't give an exact day. This is because there are several factors at play, i.e. time to port the patches, build environment updates, and build times - all of which can vary in time/complexity. For example we are currently seeing excessive build times on the Windows builder (up to 20+ hours for the three architectures), probably because of some caching issue.

The best we can do is say that we make the effort to provide a release for each supported series the first week of each month. The preparation of releases for November is underway, and the first builds should be published today.