Automated beta releases (for Chrome)

[erikdesjardins]

Resolves #2728.

This does two things:

• For tags with an odd minor version number¹ (to be used as beta releases), automatically builds and publishes the Chrome version to a beta listing
• For all version number tags, builds all targets and uploads the artifacts to a new GitHub release Automated GitHub release creation #3181

^{1: Actually, we might as well release all versions to the beta channel, so beta users don't have to switch back to the main extension for normal releases.}

Todo

• Create beta app listing in Chrome webstore (use the package from 4.7.1 and this beta icon) and private visiblity (select the google group in the dropdown and make sure you do this before first publish)
• Get Chrome webstore API OAuth tokens (client id, client secret, refresh token) and add as environment variables with these names to Travis CI
• add beta extension id to deploy.js
• Write beta instructions / disclaimers for store listing

[Ajedi32]

Pretty sure this is actually restricting all builds/tests to only those branches, not just deploys, right?

[erikdesjardins]

Yeah, but it won't effectively change anything because it only applies to branches and tags in this repo (PRs are always built).

Mainly, it's the simplest way to avoid building (and then trying to deploy) tags that don't look like version numbers.

[Ajedi32]

Seems like a reasonable idea. I've already been doing something similar to this by just using a version of RES that I built myself on my computer.

Maybe this would give more non-technical users a chance to test upcoming changes though, which could help avoid situations like in the previous release where few people were aware of the upcoming changes to night mode until after the release. Getting early feedback from users is a good thing.

For tags with an odd minor version number (to be used as beta releases)

Is there a reason you're suggesting using odd version numbers here as beta releases instead of the SemVer convention of appending -beta.0, -beta.1, etc to the version number?

From http://semver.org/#spec-item-9:

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

[jewel-andraia]

Is there a reason you're suggesting using odd version numbers here as beta releases instead of the SemVer convention of appending -beta.0, -beta.1, etc to the version number?

Yes, browsers only allow numbers and periods in version numbers.

[jewel-andraia]

Store listing / disclaimer / instructions text: https://docs.google.com/document/d/1uEyNRkB4Vg8NSgXt_tGDJ-Seth8rAsI3zC26QC7rk18/edit?usp=sharing