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: CONTRIBUTING.md
+7-6Lines changed: 7 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -351,21 +351,22 @@ The following guide is for anyone who merges a contributor pull request into the
351
351
352
352
> The following versioning system is applied since Parse Server 5.0.0 and does not necessarily apply to previous releases.
353
353
354
-
Parse Server follows [semantic versioning](https://semver.org) with a flavor of [calendric versioning](https://calver.org). Semantic versioning makes Parse Server easy to upgrade because breaking changes only occur in major releases. Calendric versioning gives an additional sense of how old a Parse Server release is and allows for future Long-Term Support concepts, which Parse Server currently does not provide.
354
+
Parse Server follows [semantic versioning](https://semver.org) with a flavor of [calendric versioning](https://calver.org). Semantic versioning makes Parse Server easy to upgrade because breaking changes only occur in major releases. Calendric versioning gives an additional sense of how old a Parse Server release is and allows for Long-Term Support of previous major releases.
- The `major` version increments with the first release of every year and may include changes that are *not backwards compatible*.
359
361
- The `minor` version increments during the year and may include new features or improvements of existing features that are backwards compatible.
360
362
- The `patch` version increments during the year and may include bug fixes that are backwards compatible.
361
363
- The `pre-release-label` is optional for pre-release versions such as:
362
364
- `-alpha` (likely to contain bugs, likely to change in features until release)
363
365
- `-beta` (likely to contain bugs, no change in features until release)
364
-
- `-rc0` (unlikely to contain bugs, no change in features until release)
366
+
- The `[pre-release-increment]` is a number that increments with every new version of a pre-release
365
367
366
368
Exceptions:
367
-
- The `major` version may increment during the year in the unlikely event that a breaking change is so urgent that it cannot wait for the next yearly release. An example would be a vulnerability fix that leads to an unavoidable breaking change.
368
-
- Bug fixes of security vulnerabilities are `patch` releases, unless they cause a breaking change, then they are `major` releases.
369
+
- The `major` version may increment during the year in the unlikely event that a breaking change is so urgent that it cannot wait for the next yearly release. An example would be a vulnerability fix that leads to an unavoidable breaking change. However, security requirements depend on the application and not every vulnerability may affect every deployment, depending on the features used. Therefore we usually prefer to deprecate insecure functionality and introduce the breaking change following our [deprecation policy](#deprecation-policy).
0 commit comments