# Improving Updates: Proposal for Releases
### Date: 2020-03-11

_Status: Looking for Feedback and Discussion_

## Overview

To help companies stay on the latest Electron versions in production, and to encourage companies to test betas, we'd like to propose slightly modifiying what changes are included in an Electron release.

In the new system, we propose that Electron-specific API changes are grouped to every _other_ release, rather than included in every release.

For example:
- Electron 12: Chromium changes only
- Electron 13: Chromium and Electron changes

## What do we mean when we say "Electron-specific" changes?

Electron needs to make changes to accomodate new versions of Chromium. However, releases often include changes that aren't driven by Chromium. Recent examples include the context-bridge API, promisifying older APIs, and depreciating the remote module.

This changes are important, and we don't want to slow or depress these changes. However, because there now seems to be a majority of apps who are having trouble staying on the latest version of Electron, we want to try to reduce upgrade friction. This proposal is an attempt to ease one point of friction.

## Rationale

- Since adopting the new cadence, participation in the AFP has dropped, reducing beta testers and the amount of bugs found during the beta cycle
- Only one app is now actively testing betas
- Issues are more likely to be found in production (e.g., two companies involved in the QA Working Group had to rollback or hotfix their Electron 7 production release).
- This makes upgrading to the latest version more difficult; more testing and trouble-shooting is required.
- Many companies require 1-2 months to upgrade Electron (from beginning to production release). Updating Electron-specific changes are often the more difficult or time-consuming parts of upgrading an app. If upgrading multiple versions at a time (e.g Electron 5 -> Electron 7), it is easy to miss depreciation warnings or documented API changes.
- Having Chromium-only versions interspliced with Electron-updated version would ease some of this friction, making it easier for more apps to stay up to date.
- More apps staying up to date would increase apps testing later/beta versions of Electron, finding bugs earlier and benefitting all apps in the ecosystem.

## Proposed Actions
- Electron 10 and 11 both contain Electron-specific work and API changes
- Electron 12 contains Chromium changes only
- From Electron 13 on:
- Every odd release contains Electron-related changes
- Every even release only contains Chromium upgrades

## Looking for Feedback

We'd love your feedback! Feedback from members who are actively driving Electron releases would be greatly appreciated, as we're sure there's context we're missing and we're also very open to alternative solutions. Any feedback would be very appreciated.