CI should run against latest Postgres versions

[cbaker6]

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

The CI isn't testing against the current latest versions of dependencies (e.g. Postgis 3.3) and still testing against dependencies that has reached the Parse EOL. This prevents the CI from determining if there are issues with the latest versions along with running unnecessary tests for each PR.

Feature / Enhancement Description

Update versions of Postgis, remove versions that have reached EOL: Postres 11, Postgis 3.0, Node 12, Mongo 4.0, Mongo MMAPv1.

Example Use Case

N/A

Alternatives / Workarounds

Test latest versions on our own.

3rd Party References

N/A

[parse-github-assistant]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[mtrezza]

Removing support for a database or node major version is a breaking change, which we'll do with Parse Server 6.
Therefore we do have specific open issues for that, e.g. #8081.

So it makes more sense to separate this PR into:

• a) Removing support for versions that won't be supported anymore by Jan 1st 2023 according to their EOL date; to be merged with release of Parse Server 6. I recommend to create a separate PR for each removal of support, because it may involve more than just changing the workflow file. For example, there are also tests that run only for specific versions, that may need to be updated.
• b) Upgrading (minor or patch versions) of currently supported versions; can be merged immediately.

Btw, MongoDB and Node.js patch versions are updated automatically with a script that detects whether there is a newer version available. It would be good if someone could extend that script to include Postgres.

[cbaker6]

a) Removing support for versions that won't be supported anymore by Jan 1st 2023 according to their EOL date; to be merged with release of Parse Server 6. I recommend to create a separate PR for each removal of support, because it may involve more than just changing the workflow file. For example, there are also tests that run only for specific versions, that may need to be updated.

For the PR, I didn't remove any code in the repo or tests, so the code to handle those versions is untouched. They are simply not tested in the CI anymore in the PR. This allows developers to manually test on old versions that have reached Parse Server EOL if they want until someone decides to remove the code in the future (see discussion here).

Btw, MongoDB and Node.js patch versions are updated automatically with a script that detects whether there is a newer version available. It would be good if someone could extend that script to include Postgres.

The Postgres components of the CI already do patch updates from the way I added them to the CI a long time ago (Minor/patch of Postgres, Minor of Postgis). Minor versions of Postgis need to be bumped manually. See the original comment in the approach section of #7176 for more

[mtrezza]

For the PR, I didn't remove any code in the repo or tests, so the code to handle those versions is untouched. They are simply not tested in the CI anymore in the PR.

We don't operate like that. A versions is officially supported by Parse Platform as long as it's tested in the CI and vice versa.

The Postgres components of the CI already do patch updates from the way I added them to the CI a long time ago

What about this change in your PR:

- name: PostgreSQL 14, PostGIS 3.2
- POSTGRES_IMAGE: postgis/postgis:14-3.2
+ name: PostgreSQL 14, PostGIS 3.3
+ POSTGRES_IMAGE: postgis/postgis:14-3.3

[cbaker6]

What about this change in your PR:

• name: PostgreSQL 14, PostGIS 3.2
• POSTGRES_IMAGE: postgis/postgis:14-3.2

• name: PostgreSQL 14, PostGIS 3.3
• POSTGRES_IMAGE: postgis/postgis:14-3.3

The sermver states:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backwards compatible manner
PATCH version when you make backwards compatible bug fixes
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Therefore what I stated earlier holds:

The Postgres components of the CI already do patch updates from the way I added them to the CI a long time ago (Minor/patch of Postgres, Minor of Postgis). Minor versions of Postgis need to be bumped manually. See the original comment in the approach section of #7176 for more

[cbaker6]

a) Removing support for versions that won't be supported anymore by Jan 1st 2023 according to their EOL date; to be merged with release of Parse Server 6.
We don't operate like that. A versions is officially supported by Parse Platform as long as it's tested in the CI and vice versa.

If this is the case, I recommend coming up with a better way to describe EOL in the README. It's currently based on dates:

which is not what your comment above states. Maybe is should be based on Parse-Server Major version releases?

[mtrezza]

Minor versions of Postgis need to be bumped manually.

Right, I overlooked that. Extending the script we use for MongoDB and Node would still be nice, it also notifies about new major / minor versions available.

I recommend coming up with a better way to describe EOL in the README.

The wording is from before we introduced calver versioning. Now we could simplify this to:

Due to the extensive PostgreSQL support duration of 5 years, Parse Server drops support about 2 years before the official end-of-life date.

Version	PostGIS Version	End-of-Life	Parse Server Support	Compatible
Postgres 11	3.0, 3.1, 3.2	November 2023	<= 5.x (2022)	✅ Yes
Postgres 12	3.2	November 2024	<= 5.x (2022)	✅ Yes
Postgres 13	3.2	November 2025	<= 6.x (2023)	✅ Yes
Postgres 14	3.2	November 2026	<= 7.x (2024)	✅ Yes

According to that, Postgres 11 should already have been unsupported from Parse Server 5. The first release date of PG 11 was October 18, 2018, so we would have supported it for >3 years. PG 12 was released October 3, 2019, so the newer version was available for >2 years before we would have dropped support. Essentially we give developers 2.25 years to upgrade to the next PG version.

Compared to MongoDB, they give developers ~2.5-2.75 years to migrate to the next higher version.
Compared to Node.js, they give developers ~2 years to migrate to the next higher LTS version.

That means in 3 months (Parse Server 6) we'll drop support for Postgres 11 and 12, but it will stay supported in our LTS branch for an additional year until end of 2023.

Does this make sense?

[parseplatformorg]

🎉 This change has been released in version 5.3.0-alpha.27

[parseplatformorg]

🎉 This change has been released in version 5.4.0-beta.1

[parseplatformorg]

🎉 This change has been released in version 5.4.0-alpha.1

[parseplatformorg]

🎉 This change has been released in version 5.4.0

[parseplatformorg]

🎉 This change has been released in version 5.4.0