From 761943ea345452b6e8d15cd9f8af08f688f535bc Mon Sep 17 00:00:00 2001 From: Manuel Trezza <5673677+mtrezza@users.noreply.github.com> Date: Tue, 23 Mar 2021 19:45:58 +0100 Subject: [PATCH 1/6] added versioning --- CONTRIBUTING.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a761f91955..a7f3c61baa 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -19,6 +19,7 @@ - [Wording Guideline](#wording-guideline) - [Parse Error](#parse-error) - [Parse Server Configuration](#parse-server-configuration) +- [Versioning](#versioning) - [Code of Conduct](#code-of-conduct) ## Contributing @@ -281,6 +282,13 @@ Introducing new [Parse Server configuration][config] parameters requires the fol 1. Add test cases to ensure the correct parameter value validation. Parse Server throws an error at launch if an invalid value is set for any configuration parameter. 1. Execute `npm run docs` to generate the documentation in the `/out` directory. Take a look at the documentation whether the description and formatting of the newly introduced parameters is satisfactory. +## Versioning + +Parse Server follows [semantic versioning](https://semver.org) with syntax `x.y.z` which defines: +- `x` is the *major* version number which means a *breaking release* that may include changes that are not backwards compatible +- `y` is the *minor* version number which means a *feature release* that may include new features, improvements or other changes that are backwards compatible +- `z` is the *patch* version number which means a *patch release* that may include bug fixes that are backwards compatible + ## Code of Conduct This project adheres to the [Contributor Covenant Code of Conduct](https://github.com/parse-community/parse-server/blob/master/CODE_OF_CONDUCT.md). By participating, you are expected to honor this code. From 645dc850a960d1fa872a5e19acb076ae2fa87cdb Mon Sep 17 00:00:00 2001 From: Manuel Trezza <5673677+mtrezza@users.noreply.github.com> Date: Wed, 24 Mar 2021 04:46:58 +0100 Subject: [PATCH 2/6] improved wording --- CONTRIBUTING.md | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a7f3c61baa..987ec8fa01 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -284,10 +284,23 @@ Introducing new [Parse Server configuration][config] parameters requires the fol ## Versioning -Parse Server follows [semantic versioning](https://semver.org) with syntax `x.y.z` which defines: -- `x` is the *major* version number which means a *breaking release* that may include changes that are not backwards compatible -- `y` is the *minor* version number which means a *feature release* that may include new features, improvements or other changes that are backwards compatible -- `z` is the *patch* version number which means a *patch release* that may include bug fixes that are backwards compatible +> The following versioning system is applied since Parse Server 5.0.0 and does not necessarily apply to previous releases. + +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. + +Syntax: `[major]`**.**`[feature]`**.**`[fix]`**-**`[pre-release-label]` + +- The `major` version increments every year and may include changes that are *not* backwards compatible. +- The `feature` version increments during the year and may include new features or improvements of existing features that are backwards compatible. +- The `fix` version increments during the year and may include bug fixes that are backwards compatible. +- The `pre-release-label` is optional for pre-release versions such as: + - `-alpha` (likely to contain bugs, likely to change in features until release) + - `-beta` (likely to contain bugs, no change in features until release) + - `-rc0` (unlikely to contain bugs, no change in features until release) + +Exceptions: +- 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. This should be as rare as the planetary alignment of Jupiter and Saturn. +- Bug fixes of security vulnerabilities are `fix` releases, unless they cause a breaking change, then they are `major` releases. ## Code of Conduct From a4ab7dc56a262e80121e255b8207bfbaa4f651ff Mon Sep 17 00:00:00 2001 From: Manuel Trezza <5673677+mtrezza@users.noreply.github.com> Date: Wed, 24 Mar 2021 04:48:48 +0100 Subject: [PATCH 3/6] fixed typo --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 987ec8fa01..480608efdf 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -286,7 +286,7 @@ Introducing new [Parse Server configuration][config] parameters requires the fol > The following versioning system is applied since Parse Server 5.0.0 and does not necessarily apply to previous releases. -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. +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. Syntax: `[major]`**.**`[feature]`**.**`[fix]`**-**`[pre-release-label]` From fcc8b97eed74d4e3e8ec9c9cf3a96658c906e4aa Mon Sep 17 00:00:00 2001 From: Manuel Trezza <5673677+mtrezza@users.noreply.github.com> Date: Fri, 26 Mar 2021 23:55:17 +0100 Subject: [PATCH 4/6] renamed version segments to traditional --- CONTRIBUTING.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 480608efdf..0153fea841 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -288,19 +288,19 @@ Introducing new [Parse Server configuration][config] parameters requires the fol 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. -Syntax: `[major]`**.**`[feature]`**.**`[fix]`**-**`[pre-release-label]` +Syntax: `[major]`**.**`[minor]`**.**`[patch]`**-**`[pre-release-label]` - The `major` version increments every year and may include changes that are *not* backwards compatible. -- The `feature` version increments during the year and may include new features or improvements of existing features that are backwards compatible. -- The `fix` version increments during the year and may include bug fixes that are backwards compatible. +- The `minor` version increments during the year and may include new features or improvements of existing features that are backwards compatible. +- The `patch` version increments during the year and may include bug fixes that are backwards compatible. - The `pre-release-label` is optional for pre-release versions such as: - `-alpha` (likely to contain bugs, likely to change in features until release) - `-beta` (likely to contain bugs, no change in features until release) - `-rc0` (unlikely to contain bugs, no change in features until release) Exceptions: -- 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. This should be as rare as the planetary alignment of Jupiter and Saturn. -- Bug fixes of security vulnerabilities are `fix` releases, unless they cause a breaking change, then they are `major` releases. +- 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. This should be as rare as the planetary alignment of Jupiter and Saturn. +- Bug fixes of security vulnerabilities are `patch` releases, unless they cause a breaking change, then they are `major` releases. ## Code of Conduct From 32b8274d6f239d7401c8ac6d7418892e567cce46 Mon Sep 17 00:00:00 2001 From: Manuel Trezza <5673677+mtrezza@users.noreply.github.com> Date: Sun, 2 May 2021 15:15:46 +0200 Subject: [PATCH 5/6] update --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0153fea841..7c6184c43e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -290,7 +290,7 @@ Parse Server follows [semantic versioning](https://semver.org) with a flavor of Syntax: `[major]`**.**`[minor]`**.**`[patch]`**-**`[pre-release-label]` -- The `major` version increments every year and may include changes that are *not* backwards compatible. +- The `major` version increments with the first release of every year and may include changes that are *not* backwards compatible. - The `minor` version increments during the year and may include new features or improvements of existing features that are backwards compatible. - The `patch` version increments during the year and may include bug fixes that are backwards compatible. - The `pre-release-label` is optional for pre-release versions such as: @@ -299,7 +299,7 @@ Syntax: `[major]`**.**`[minor]`**.**`[patch]`**-**`[pre-release-label]` - `-rc0` (unlikely to contain bugs, no change in features until release) Exceptions: -- 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. This should be as rare as the planetary alignment of Jupiter and Saturn. +- 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. - Bug fixes of security vulnerabilities are `patch` releases, unless they cause a breaking change, then they are `major` releases. ## Code of Conduct From 73a2e2ef77c23b7a3db71e5d043addfb32986c32 Mon Sep 17 00:00:00 2001 From: Manuel Trezza <5673677+mtrezza@users.noreply.github.com> Date: Sun, 31 Oct 2021 21:38:06 +0100 Subject: [PATCH 6/6] Update CONTRIBUTING.md --- CONTRIBUTING.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 845f4efaca..7e620fbc78 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -351,21 +351,22 @@ The following guide is for anyone who merges a contributor pull request into the > The following versioning system is applied since Parse Server 5.0.0 and does not necessarily apply to previous releases. -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. +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. -Syntax: `[major]`**.**`[minor]`**.**`[patch]`**-**`[pre-release-label]` +Example version: `5.0.0-alpha.1` -- The `major` version increments with the first release of every year and may include changes that are *not* backwards compatible. +Syntax: `[major]`**.**`[minor]`**.**`[patch]`**-**`[pre-release-label]`**.**`[pre-release-increment]` + +- The `major` version increments with the first release of every year and may include changes that are *not backwards compatible*. - The `minor` version increments during the year and may include new features or improvements of existing features that are backwards compatible. - The `patch` version increments during the year and may include bug fixes that are backwards compatible. - The `pre-release-label` is optional for pre-release versions such as: - `-alpha` (likely to contain bugs, likely to change in features until release) - `-beta` (likely to contain bugs, no change in features until release) - - `-rc0` (unlikely to contain bugs, no change in features until release) +- The `[pre-release-increment]` is a number that increments with every new version of a pre-release Exceptions: -- 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. -- Bug fixes of security vulnerabilities are `patch` releases, unless they cause a breaking change, then they are `major` releases. +- 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). ## Code of Conduct