Bump CI environment, remove Postgres 10 support

[mtrezza]

• Bump Node
• Bump MongoDB
• Remove Postgres 10 support
• Remove COVERAGE_OPTION

[codecov]

Codecov Report

Merging #7323 (90a7c40) into master (a28433f) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

❗ Current head 90a7c40 differs from pull request most recent head e6ae524. Consider uploading reports for the commit e6ae524 to get more accurate results

@@            Coverage Diff             @@
##           master    #7323      +/-   ##
==========================================
- Coverage   93.90%   93.89%   -0.01%     
==========================================
  Files         181      181              
  Lines       13194    13194              
==========================================
- Hits        12390    12389       -1     
- Misses        804      805       +1     

Impacted Files	Coverage Δ
src/Auth.js	100.00% <ø> (ø)
src/Controllers/AdaptableController.js	95.65% <ø> (-0.35%)	⬇️
src/Controllers/UserController.js	97.67% <100.00%> (+0.03%)	⬆️
src/RestWrite.js	94.08% <100.00%> (+0.08%)	⬆️
src/Routers/SessionsRouter.js	91.42% <100.00%> (+0.25%)	⬆️
src/Routers/UsersRouter.js	93.78% <100.00%> (+0.03%)	⬆️
...dapters/Storage/Postgres/PostgresStorageAdapter.js	95.36% <0.00%> (-0.16%)	⬇️
src/ParseServerRESTController.js	98.50% <0.00%> (+1.49%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a28433f...e6ae524. Read the comment docs.

[mtrezza]

@cbaker6 There seems to be a discrepancy between the CI environment and the Postgres support table:

For example, from the table I'd assume that we test against Postgres 10, PostGIS 3.0, but that is not the case. Should the table be corrected or am I missing something? And do you know what is the reason for the current selection of Postgres / PostGIS combinations, it seems rather arbitrary? Maybe we can reduce the number of Postgres tests?

[mtrezza]

Currently failing for MongoDB 4.4.5 due to issue with mongodb-runner, see mongodb-js/runner#185; this should self-resolve in a few hours / days.

[cbaker6]

For example, from the table I'd assume that we test against Postgres 10, PostGIS 3.0, but that is not the case. Should the table be corrected or am I missing something?

if a 3.0 test passes on 1 and 3.1 test passes on all, it’s highly unlikely that 3.0 doesn’t pass on the others. For parse none of the methods (which are only a few) we use in postgis changed between 3.0 and 3.1, so technically if one works the other should work. If you don’t want 3.0 to be there because it not tested on the others, then it’s okay to remove. The developer can test it.

And do you know what is the reason for the current selection of Postgres / PostGIS combinations, it seems rather arbitrary?

What combinations are arbitrary? Those were the latest of each version when they were added to the CI and includes their patches automatically. An additional test of Postgis 3.0 is run on 12 because 3.1 came out around the time of 13, so people are more than likely to use 3.1 with Postgres 13.

Maybe we can reduce the number of Postgres tests?

I’m assuming you mean remove the 3.0 tests? I don’t see any others that should be up for consideration. When the Postgres PR was created, there were multiple configs of Mongo being tested so I made sure to add the common configs for Postgres. If 3.0 gets removed, it’s not necessarily a big deal. Removing any others I’m against, and I’m for testing against Postgres fairly since I hopped in the discussion #6374 when dropping support for Postgres was being considered. Particularly when other BaaS’s are touting they are unique because they work with Postgres. I think it is less known that Parse has worked seamlessly with Mongo and Postgres for years and the others touting Postgres support are pretty far behind Parse. Do I think we need to test 10-13? Not really, but we had that convo on the original thread.

[mtrezza]

@cbaker6 Thanks for explaining.

Looking at PostGIS releases:

• PostGIS 3.0 was released in 10/2019
• PostGIS 3.1 was released in 01/2021 --> this is fairly young, I think removing 3.0 support would be premature

Looking at Postgres releases:

• Postgres 10 was released in 10/2017 --> this was 3.5 years ago
• Postgres 11 was released in 10/2018
• Postgres 12 was released in 10/2019
• Postgres 13 was released in 9/2020

For comparison:

• Node.js has a LTS duration of 1.5 years
• MongoDB has a LTS duration of 3.5 years
• Postgres has a LTS duration of 5 years

The conclusion is that Postgres has a longer LTS duration, that seems to be a legacy of the waterfall paradigm, it has kept the 5 year duration since 1998. Of course a DB system is not as easy to migrate as Node and I would normally say that Parse Server should respect the LTS dates of its key components. But we could consider an exception for Postgres. Supporting a 5 year old system may be somewhat unusual today.

@cbaker6, @dplewis What would you say if we remove official Postgres 10 support and cut the official Postgres support dates to 3.5 years which is the same LTS duration as MongoDB?

[cbaker6]

Removing 10 is fine IMO. When we were last using travis, it was only tested against 11. I think 10 was being tested over 1.5 years ago in the CI. If I remember correctly, @dplewis did the original postgres bump from 10 to 11

[mtrezza]

This PR temporarily disables the CI Check for MongoDB 4.4.5 because the version is not available for download via mongodb-runner yet.

[mtrezza]

@dplewis @davimacedo If there is no objection, I will merge this later today, dropping Postgres 10 support.

Dropped Postgres 10 support (>3.5 years old)
We then will test with:

• PostgreSQL 11, PostGIS 3.0
• PostgreSQL 11, PostGIS 3.1
• PostgreSQL 12, PostGIS 3.1
• PostgreSQL 13, PostGIS 3.1

Intention is to keep PostGIS 3.0 test always on the oldest PostgreSQL version, so we have a system. We do the same with MongoDB where we test standalone (and MMAPv1) on the oldest MongoDB version.

[parseplatformorg]

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

[parseplatformorg]

🎉 This change has been released in version 5.0.0