New release schedule proposal

[Tyriar]

cc @zeke @cifratila @jkleinsc @tonyganch @vanessayuenn

[zeke]

Thanks for putting this together, @Tyriar. Overall I think it's looking great. Will add more actionable feedback soon when I'm fresh. 👍

[sedwards2009]

As a downstream user of Electron, what I'm missing from the document is a clear statement about how long major/minor branches are supported and receive bug fix releases.

[Tyriar]

@sedwards2009 I'm not sure if it's captured currently, but the proposal is that Electron will support the current stable minor build (eg. 2.1.x) and the following beta build (eg. 2.2.0-betay). Back-porting fixes beyond that current stable minor build would only be done in exceptional circumstances. Instead the focus should be to keep the app up to date.

[sedwards2009]

@Tyriar Yes, a line like that in the document would help clear things up. Although I wouldn't use the word 'current'. The definition of 'current' can vary a bit between projects. I think the word 'latest' is clearer.

[welcome]

Congrats on merging your first pull request! 🎉🎉🎉

[zeke]

Merged this into the document-prereleases branch. We can keep working on it in #10336 before it lands on master.

[michaeljota]

As Electron user, and other semantic based popular software, I was wondering maybe with this you could create a schedule release of Electron, and even have LTS versions, if you follow the Node release.

Taking for example, the current LTS Node version, 8 LTS, a Electron version based on this one, could also be considered LTS.

Also, you may synchronize the major version bump, to include every item in your checklist, meaning that a major version bump (From 2 to 3) would include a new version of Node AND a new version of Chromium AND every Electron breaking change API. Then, you would have a release every six months, after Node updates.

IDK, maybe this was already in your roadmap, but currently it seems like you can release a new version of Electron every now and then, then you need either a new version of Node OR a new version of Chromium OR introduce a Electron breaking change API.

Either way, I really enjoy reading this document, and think this is a great way to software version.

[MarshallOfSound]

and even have LTS versions

The issue here is we can only support what our upstream dependencies support, so even though node has LTS's, for security reasons chromium does not. We can't effectively maintain LTS releases because 90% of our time would be spent backporting patches from newer chromium versions to older ones. This is simply not sustainable, for the foreseeable future this release schedule is probably what we'll be following 😄