* Update version parsing to allow rollback release
When we want to rollback a release on Chrome, sometimes we use the
fourth part of the version for the rollback release. This is because
the Chrome web stores does not directly allow rolling back, but instead
requires us to re-submit the release we want to roll back to with a
higher version number.
The manifest version parsing now allows for a fourth version part.
The comments have also been updated to be more descriptive, and to fix
a minor inaccuracy.
* Fix typo in comment
Co-authored-by: David Walsh <davidwalsh83@gmail.com>
Co-authored-by: David Walsh <davidwalsh83@gmail.com>
* deprecate extensionizer for webextension-polyfill
* fix tests
* remove extensionizer
* fix browser windows api calls
* fix broken on firefox
* fix getAcceptLanguages call
* update more browser apis that are now promisified
* remove unnecessary console error ignoring in e2e tests
The Firefox extension version format does not support the version
format we use (SemVer), so we have to specially format the extension
version to be compatible. The format we chose was
`[major].[minor].[patch].[buildType][buildVersion]`. But when we tried
to submit a build with a version in that format, it was rejected as
invalid for unknown reasons.
The Firefox extension format has been updated to
`[major].[minor].[patch][buildType][buildVersion]`. This seems to pass
validation.
The `version_name` manifest field was being used on Chrome to store the
build type. However, Chrome intended this field to be a full
representation of the version, for display purposes. This was evident
when uploading this version to the Chrome Web Store, because it used
`flask` as the entire version.
Instead the `version_name` field now includes the full SemVer version
string. The version parsing code within the build script and in the
wallet itself have been updated accordingly.
The extension version used throughout the wallet is now normalized to a
SemVer-compliant version that matches the version used in
`package.json`. We use this version for display on the "About" page,
and we attach it to all error reports and metric events, so it's
important that we format it consistently so that we can correlate
events on the same version across different browsers.
This normalization step is necessary because Firefox and Chrome both
have different requirements for the extension version, and neither is
SemVer-compliant.
