You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/tutorial/electron-versioning.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,7 +32,7 @@ There are several major changes from our 1.x strategy outlined below. Each chang
32
32
2. Introduction of semver-compliant `-beta` tags
33
33
3. Introduction of [conventional commit messages](https://conventionalcommits.org/)
34
34
4. Clearly defined stabilization branches
35
-
5. The `master` branch is versionless; only stability branches contain version information
35
+
5. The `master` branch is versionless; only stabilization branches contain version information
36
36
37
37
We will cover in detail how git branching works, how npm tagging works, what developers should expect to see, and how one can backport changes.
38
38
@@ -52,7 +52,7 @@ Below is a table explicitly mapping types of changes to their corresponding cate
52
52
***Patch Version Increments**
53
53
* node.js patch version updates
54
54
* fix-related chromium patches
55
-
* electron bug fixes
55
+
* Electron bug fixes
56
56
57
57
Note that most chromium updates will be considered breaking. Fixes that can be backported will likely be cherry-picked as patches.
58
58
@@ -91,7 +91,7 @@ e.g. `2.0.0`.
91
91
4. If future bug fixes or security patches need to be made once a release is stable, they are applied and the _patch_ version is incremented accordingly
92
92
e.g. `2.0.1`.
93
93
94
-
For each major and minor bump, you should expect too see something like the following:
94
+
For each major and minor bump, you should expect to see something like the following:
95
95
96
96
```text
97
97
2.0.0-beta.1
@@ -106,11 +106,11 @@ An example lifecycle in pictures:
106
106
107
107
* A new release branch is created that includes the latest set of features. It is published as `2.0.0-beta.1`.
108
108
109
-
* A bug fix comes into master that can be pack-ported to the release branch. The patch is applied, and a new beta is published as `2.0.0-beta.2`.
109
+
* A bug fix comes into master that can be backported to the release branch. The patch is applied, and a new beta is published as `2.0.0-beta.2`.
110
110
111
111
* The beta is considered _generally stable_ and it is published again as a non-beta under `2.0.0`.
112
112
113
-
* Later, a zero-day exploit is revealed and a fix is applied to master. We pack-port the fix to the `2-0-x` line and release `2.0.1`.
113
+
* Later, a zero-day exploit is revealed and a fix is applied to master. We backport the fix to the `2-0-x` line and release `2.0.1`.
114
114
115
115
116
116
A few examples of how various semver ranges will pick up new releases:
@@ -128,7 +128,7 @@ As a future consideration, we may introduce one or both of the following:
128
128
# Feature Flags
129
129
Feature flags are a common practice in Chromium, and are well-established in the web-development ecosystem. In the context of Electron, a feature flag or **soft branch** must have the following properties:
130
130
131
-
*is is enabled/disabled either at runtime, or build-time; we do not support the concept of a request-scoped feature flag
131
+
*it is enabled/disabled either at runtime, or build-time; we do not support the concept of a request-scoped feature flag
132
132
* it completely segments new and old code paths; refactoring old code to support a new feature _violates_ the feature-flag contract
133
133
* feature flags are eventually removed after the soft-branch is merged
0 commit comments