Merge branch 'upstream/alpha' into beta-pkg-2-collation

# Conflicts: # package-lock.json # package.json
parse-community · Apr 19, 2022 · bb299d5 · bb299d5
2 parents edc1cc2 + 8b91961
commit bb299d5
Show file tree

Hide file tree

Showing 59 changed files with 2,506 additions and 753 deletions.
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
@@ -6,7 +6,7 @@ on:
     branches:
       - '**'
 env:
-  NODE_VERSION: 16.13.0
+  NODE_VERSION: 16.14.2
   PARSE_SERVER_TEST_TIMEOUT: 20000
 jobs:
   check-ci:
@@ -101,47 +101,57 @@ jobs:
     strategy:
       matrix:
         include:
+          - name: MongoDB 5.2, ReplicaSet, WiredTiger
+            MONGODB_VERSION: 5.2.1
+            MONGODB_TOPOLOGY: replicaset
+            MONGODB_STORAGE_ENGINE: wiredTiger
+            NODE_VERSION: 14.19.1
+          - name: MongoDB 5.1, ReplicaSet, WiredTiger
+            MONGODB_VERSION: 5.1.1
+            MONGODB_TOPOLOGY: replicaset
+            MONGODB_STORAGE_ENGINE: wiredTiger
+            NODE_VERSION: 14.19.1
           - name: MongoDB 5.0, ReplicaSet, WiredTiger
-            MONGODB_VERSION: 5.0.3
+            MONGODB_VERSION: 5.0.6
             MONGODB_TOPOLOGY: replicaset
             MONGODB_STORAGE_ENGINE: wiredTiger
-            NODE_VERSION: 16.13.0
+            NODE_VERSION: 16.14.2
           - name: MongoDB 4.4, ReplicaSet, WiredTiger
-            MONGODB_VERSION: 4.4.10
+            MONGODB_VERSION: 4.4.13
             MONGODB_TOPOLOGY: replicaset
             MONGODB_STORAGE_ENGINE: wiredTiger
-            NODE_VERSION: 16.13.0
+            NODE_VERSION: 16.14.2
           - name: MongoDB 4.2, ReplicaSet, WiredTiger
-            MONGODB_VERSION: 4.2.17
+            MONGODB_VERSION: 4.2.19
             MONGODB_TOPOLOGY: replicaset
             MONGODB_STORAGE_ENGINE: wiredTiger
-            NODE_VERSION: 16.13.0
+            NODE_VERSION: 16.14.2
           - name: MongoDB 4.0, ReplicaSet, WiredTiger
-            MONGODB_VERSION: 4.0.27
+            MONGODB_VERSION: 4.0.28
             MONGODB_TOPOLOGY: replicaset
             MONGODB_STORAGE_ENGINE: wiredTiger
-            NODE_VERSION: 16.13.0
+            NODE_VERSION: 16.14.2
           - name: MongoDB 4.0, Standalone, MMAPv1
-            MONGODB_VERSION: 4.0.27
+            MONGODB_VERSION: 4.0.28
             MONGODB_TOPOLOGY: standalone
             MONGODB_STORAGE_ENGINE: mmapv1
-            NODE_VERSION: 16.13.0
+            NODE_VERSION: 16.14.2
           - name: Redis Cache
             PARSE_SERVER_TEST_CACHE: redis
-            MONGODB_VERSION: 4.4.10
+            MONGODB_VERSION: 4.4.13
             MONGODB_TOPOLOGY: standalone
             MONGODB_STORAGE_ENGINE: wiredTiger
-            NODE_VERSION: 16.13.0
+            NODE_VERSION: 16.14.2
           - name: Node 12
-            MONGODB_VERSION: 4.4.10
+            MONGODB_VERSION: 4.4.13
             MONGODB_TOPOLOGY: standalone
             MONGODB_STORAGE_ENGINE: wiredTiger
-            NODE_VERSION: 12.22.7
+            NODE_VERSION: 12.22.11
           - name: Node 14
-            MONGODB_VERSION: 4.4.10
+            MONGODB_VERSION: 4.4.13
             MONGODB_TOPOLOGY: standalone
             MONGODB_STORAGE_ENGINE: wiredTiger
-            NODE_VERSION: 14.18.1
+            NODE_VERSION: 14.19.1
       fail-fast: false
     name: ${{ matrix.name }}
     timeout-minutes: 15
@@ -183,22 +193,22 @@ jobs:
         include:
           - name: PostgreSQL 11, PostGIS 3.0
             POSTGRES_IMAGE: postgis/postgis:11-3.0
-            NODE_VERSION: 16.13.0
+            NODE_VERSION: 16.14.2
           - name: PostgreSQL 11, PostGIS 3.1
             POSTGRES_IMAGE: postgis/postgis:11-3.1
-            NODE_VERSION: 16.13.0
+            NODE_VERSION: 16.14.2
           - name: PostgreSQL 11, PostGIS 3.2
             POSTGRES_IMAGE: postgis/postgis:11-3.2
-            NODE_VERSION: 16.13.0
+            NODE_VERSION: 16.14.2
           - name: PostgreSQL 12, PostGIS 3.2
             POSTGRES_IMAGE: postgis/postgis:12-3.2
-            NODE_VERSION: 16.13.0
+            NODE_VERSION: 16.14.2
           - name: PostgreSQL 13, PostGIS 3.2
             POSTGRES_IMAGE: postgis/postgis:13-3.2
-            NODE_VERSION: 16.13.0
+            NODE_VERSION: 16.14.2
           - name: PostgreSQL 14, PostGIS 3.2
             POSTGRES_IMAGE: postgis/postgis:14-3.2
-            NODE_VERSION: 16.13.0
+            NODE_VERSION: 16.14.2
       fail-fast: false
     name: ${{ matrix.name }}
     timeout-minutes: 15

diff --git a/.github/workflows/release-automated.yml b/.github/workflows/release-automated.yml
@@ -30,7 +30,7 @@ jobs:
       - run: npx semantic-release
         env:
           GH_TOKEN: ${{ secrets.RELEASE_GITHUB_TOKEN }}
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          GITHUB_TOKEN: ${{ secrets.RELEASE_GITHUB_TOKEN }}
           NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
       - name: Determine tag on current commit
         id: tag

diff --git a/.madgerc b/.madgerc
@@ -0,0 +1,10 @@
+{
+	"detectiveOptions": {
+		"ts": {
+			"skipTypeImports": true
+		},
+    "es6": {
+			"skipTypeImports": true
+		}
+	}
+}
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -42,8 +42,7 @@ Details:
 - Suitable environment: experimental
 
 
-[log_release]: https://github.com/parse-community/parse-server/blob/release/CHANGELOG.md
-<!--[log_release]: https://github.com/parse-community/parse-server/blob/release/changelogs/CHANGELOG_release.md -->
+[log_release]: https://github.com/parse-community/parse-server/blob/release/changelogs/CHANGELOG_release.md
 [log_beta]: https://github.com/parse-community/parse-server/blob/beta/changelogs/CHANGELOG_beta.md
 [log_alpha]: https://github.com/parse-community/parse-server/blob/alpha/changelogs/CHANGELOG_alpha.md
 [branch_release]: https://github.com/parse-community/parse-server/tree/release

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -22,6 +22,11 @@
 - [Pull Request](#pull-request)
   - [Breaking Change](#breaking-change)
 - [Merging](#merging)
+  - [Breaking Change](#breaking-change-1)
+  - [Reverting](#reverting)
+- [Releasing](#releasing)
+  - [General Considerations](#general-considerations)
+  - [Major Release / Long-Term-Support](#major-release--long-term-support)
 - [Versioning](#versioning)
 - [Code of Conduct](#code-of-conduct)
 
@@ -303,7 +308,7 @@ For release automation, the title of pull requests needs to be written in a defi
 ```
 
 The _type_ is the category of change that is made, possible types are:
-- `feat` - add a new feature
+- `feat` - add a new feature or improve an existing feature
 - `fix` - fix a bug
 - `refactor` - refactor code without impact on features or performance
 - `docs` - add or edit code comments, documentation, GitHub pages
@@ -335,17 +340,69 @@ If a pull request contains a braking change, the description of the pull request
 
 The following guide is for anyone who merges a contributor pull request into the working branch, the working branch into a release branch, a release branch into another release branch, or any other direct commits such as hotfixes into release branches or the working branch.
 
-- For changelog generation, only the commit message set when merging the pull request is relevant. The title and description of the GitHub pull request as authored by the contributor have no influence on the changelog generation. However, the title of the GitHub pull request should be used as the commit message.
-- If the pull request contains a breaking change, the commit message must contain the phrase `BREAKING CHANGE`, capitalized and without any formatting, followed by a short description of the breaking change and ideally how the developer should address it, all in a single line. This line should contain more details focusing on the "breaking” aspect of the change and is intended to assist the developer in adapting. Keep it concise, as it will become part of the changelog entry, for example:
+- A contributor pull request must be merged into the working branch using `Squash and Merge`, to create a single commit message that describes the change.
+- A release branch or the default branch must be merged into another release branch using `Merge Commit`, to preserve each individual commit message that describes its respective change.
+- For changelog generation, only the commit message set when merging the pull request is relevant. The title and description of the GitHub pull request as authored by the contributor have no influence on the changelog generation. However, the title of the GitHub pull request should be used as the commit message. See the following chapters for considerations in special scenarios, e.g. merging a breaking change or reverting a commit.
+
+### Breaking Change
+
+If the pull request contains a breaking change, the commit message must contain the phrase `BREAKING CHANGE`, capitalized and without any formatting, followed by a short description of the breaking change and ideally how the developer should address it, all in a single line. This line should contain more details focusing on the "breaking” aspect of the change and is intended to assist the developer in adapting. Keep it concise, as it will become part of the changelog entry, for example:
 
   ```
   fix: remove handle from door
   
   BREAKING CHANGE: You cannot open the door anymore by using a handle. See the [#migration guide](http://example.com) for more details.
   ```
   Keep in mind that in a repository with release automation, merging such a commit message will trigger a release with a major version increment.
-- A contributor pull request must be merged into the working branch using `Squash and Merge`, to create a single commit message that describes the change.
-- A release branch or the default branch must be merged into another release branch using `Merge Commit`, to preserve each individual commit message that describes its respective change.
+
+### Reverting
+
+If the commit reverts a previous commit, use the prefix `revert:`, followed by the header of the reverted commit. In the body of the commit message add `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted. For example:
+
+  ```
+  revert: fix: remove handle from door
+  
+  This reverts commit 1234567890abcdef.
+  ```
+
+⚠️ A `revert` prefix will *always* trigger a release. Generally, a commit that did not trigger a release when it was initially merged should also not trigger a release when it is reverted. For example, do not use the `revert` prefix when reverting a commit that has a `ci` prefix:
+
+  ```
+  ci: add something
+  ```
+  is reverted with:
+  ```
+  ci: remove something
+  ```
+  instead of:
+  ```
+  revert: ci: add something
+  
+  This reverts commit 1234567890abcdef.
+  ```
+
+## Releasing
+
+### General Considerations
+
+- The `package-lock.json` file has to be deleted and recreated by npm from scratch in regular intervals using the `npm i` command. It is not enough to only update the file via automated security pull requests (e.g. dependabot, snyk), that can create inconsistencies between sub-devependencies of a dependency and increase the chances of vulnerabilities. The file should be recreated once every release cycle which is usually monthly.
+
+### Major Release / Long-Term-Support
+
+Long-Term-Support (LTS) is provided for the previous Parse Server major version. For example, Parse Server 4.x will receive security updates until Parse Server 5.x is superseded by Parse Server 6.x and becomes the new LTS version. While the current major version is published on branch `release`, a LTS version is published on branch `release-#.x.x`, for example `release-4.x.x` for the Parse Server 4.x LTS branch. 
+
+#### Preparing Release
+
+The following changes are done in the `alpha` branch, before publishing the last `beta` version that will eventually become the major release. This way the changes trickle naturally through all branches and code consistency is ensured among branches.
+
+- Make sure all [deprecations](https://github.com/parse-community/parse-server/blob/alpha/DEPRECATIONS.md) are reflected in code, old code is removed and the deprecations table is updated.
+- Add the future LTS branch `release-#.x.x` to the branch list in [release.config.js](https://github.com/parse-community/parse-server/blob/alpha/release.config.js) so that the branch will later be recognized for release automation.
+
+#### Publishing Release
+
+1. Create LTS branch `release-#.x.x` off the latest version tag on `release` branch.
+2. Create temporary branch `build-release` off branch `beta` and create a pull request with `release` as the base branch.
+3. Merge branch `build-release` into `release`. Given that there will be breaking changes, a new major release will be created. In the unlikely case that there have been no breaking changes between the previous major release and the upcoming release, a major version increment has to be triggered manually. See the docs of the release automation framework for how to do that.
 
 ## Versioning
 

diff --git a/README.md b/README.md
@@ -112,32 +112,34 @@ Before you start make sure you have installed:
 #### Node.js
 Parse Server is continuously tested with the most recent releases of Node.js to ensure compatibility. We follow the [Node.js Long Term Support plan](https://github.com/nodejs/Release) and only test against versions that are officially supported and have not reached their end-of-life date.
 
-| Version    | Latest Version | End-of-Life | Compatible    |
-|------------|----------------|-------------|---------------|
-| Node.js 12 | 12.22.7        | April 2022  | ✅ Yes        |
-| Node.js 14 | 14.18.1        | April 2023  | ✅ Yes        |
-| Node.js 16 | 16.13.0        | April 2024  | ✅ Yes        |
+| Version    | Latest Version | End-of-Life | Compatible   |
+|------------|----------------|-------------|--------------|
+| Node.js 12 | 12.22.11        | April 2022  | ✅ Yes        |
+| Node.js 14 | 14.19.1        | April 2023  | ✅ Yes        |
+| Node.js 16 | 16.14.2        | April 2024  | ✅ Yes        |
 | Node.js 17 | 17.x           | June 2022   | ❌ Not tested |
 
 #### MongoDB
 Parse Server is continuously tested with the most recent releases of MongoDB to ensure compatibility. We follow the [MongoDB support schedule](https://www.mongodb.com/support-policy) and only test against versions that are officially supported and have not reached their end-of-life date.
 
-| Version     | Latest Version | End-of-Life  | Compatible |
-|-------------|----------------|--------------|------------|
-| MongoDB 4.0 | 4.0.27         | April 2022   | ✅ Yes     |
-| MongoDB 4.2 | 4.2.17         | TBD          | ✅ Yes     |
-| MongoDB 4.4 | 4.4.10         | TBD          | ✅ Yes     |
-| MongoDB 5.0 | 5.0.3          | January 2024 | ✅ Yes     |
-
+| Version     | Latest Version | End-of-Life | Compatible |
+|-------------|----------------|-------------|------------|
+| MongoDB 4.0 | 4.0.28         | April 2022  | ✅ Yes      |
+| MongoDB 4.2 | 4.2.19         | TBD         | ✅ Yes      |
+| MongoDB 4.4 | 4.4.13         | TBD         | ✅ Yes      |
+| MongoDB 5.0 | 5.0.6          | TBD         | ✅ Yes      |
+| MongoDB 5.1 | 5.1.1          | TBD         | ✅ Yes      |
+| MongoDB 5.2 | 5.2.1          | TBD         | ✅ Yes      |
+
 #### PostgreSQL
 Parse Server is continuously tested with the most recent releases of PostgreSQL and PostGIS to ensure compatibility, using [PostGIS docker images](https://registry.hub.docker.com/r/postgis/postgis/tags?page=1&ordering=last_updated). We follow the [PostgreSQL support schedule](https://www.postgresql.org/support/versioning) and [PostGIS support schedule](https://www.postgis.net/eol_policy/) and only test against versions that are officially supported and have not reached their end-of-life date. Due to the extensive PostgreSQL support duration of 5 years, Parse Server drops support if a version is older than 3.5 years and a newer version has been available for at least 2.5 years.
 
 | Version     | PostGIS Version | End-of-Life   | Parse Server Support End | Compatible |
 |-------------|-----------------|---------------|--------------------------|------------|
-| Postgres 11 | 3.0, 3.1, 3.2   | November 2023 | April 2022               | ✅ Yes     |
-| Postgres 12 | 3.2             | November 2024 | April 2023               | ✅ Yes     |
-| Postgres 13 | 3.2             | November 2025 | April 2024               | ✅ Yes     |
-| Postgres 14 | 3.2             | November 2026 | April 2025               | ✅ Yes     |
+| Postgres 11 | 3.0, 3.1, 3.2   | November 2023 | April 2022               | ✅ Yes      |
+| Postgres 12 | 3.2             | November 2024 | April 2023               | ✅ Yes      |
+| Postgres 13 | 3.2             | November 2025 | April 2024               | ✅ Yes      |
+| Postgres 14 | 3.2             | November 2026 | April 2025               | ✅ Yes      |
 
 ### Locally
 ```bash