Parse Server 6 release

[mtrezza]

Parse Server 6

This is to prepare for Parse Server 6 release in Jan 2023.

Schedule

• Nov 2022: Merge breaking changes into alpha to create 6.0.0-alpha releases
• Dec 2022:
  1. Feature freeze for alpha branch until Parse Server 6.0 release
  2. Merge beta into release to release last Parse Server 5 stable version before LTS
  3. Merge alpha into beta to release 6.0.0-beta
• Jan 2023: Merge beta into release to release 6.0.0

Issues / PRs to merge in Nov 2022

The following items are required or reasonable to do before a major release, since they involve breaking changes or relate to obsolete features that should be dropped. The list does not consider features or bugs that are unrelated to the aforementioned aspects and can therefore be merged at any time, unrelated to a major release.

Required

• Remove deprecations
  • Remove deprecation DEPPS1: Native MongoDB syntax in aggregation pipeline #8268
  • Remove deprecation DEPPS2: Config option directAccess defaults to true #8269
  • Remove deprecation DEPPS3: Config option enforcePrivateUsers defaults to true #8270
  • Remove deprecation DEPPS4: Remove convenience method for http request Parse.Cloud.httpRequest #8271
• Remove Node 12 and Node 17 support #8081
• Remove support for MongoDB 4.0 #8272
• Replace standalone MMAPv1 CI test and replace with standalone WT #8273
• Adapt branches and release automation for Parse Server 5 LTS (remove Parse Server 4 LTS) #8275
• Server crashes when throwing inside Cloud Code trigger #8255
• Upgrade Redis 3 to 4 #8276
• Parse Server may expose HTTP routes before complete initialization #7527
• Restrict access scope of master key #8218
• verifyServerUrl does not work with new startup methods #8380
• Docker image doesn't conform to best practices #8360
• Upgrade to Parse JS SDK 4 #8330
• docs: Consolidate LICENSE and PATENTS clauses into Apache 2.0 #8408
• Upgrade to latest JS SDK #8412

Optional (planned)

• Nested Date type attributes are saved differently at different levels #7575
• Restrict use of masterKey to localhost by default #8245
• Improve transparency of reset password flow #7434 (not a braking change)
• fix: GraphIQL offline install #8153 (not a braking change)
• LiveQuery fields does not work as expected #8027 (not a breaking change)
• refactor: error messages reformatted and moved into own files (#1731) #7446
• Define built-in error code range docs#943

Optional (to be discussed)

• Remove CI check "NPM lock file version" and regenerate package-lock.json as v2 #8274
• Modernize Auth Adapter #7042
• Remove Node 14 support (EOL will be in Apr 2023) (we'll keep Node 14 until Parse Server 7 (2024))
• Remove GraphQL API from codebase #7979 (likely a huge effort and a major change that should go though alpha / beta testing first)
• fix: mongo explain queries should always return as an array of results #7440 (major change affecting also Parse client SDKs?)
• Modernize API doc template #8017 (just a nice-to-have for the new major release)

[parse-github-assistant]

Thanks for opening this issue!

[dblythy]

Some suggestions for breaking changes (alongside the current deprecations, https://github.com/parse-community/parse-server/blob/alpha/DEPRECATIONS.md):

• Nested objects encoding change: fix: Nested objects are encoded incorrectly for MongoDB #8209
• Disable auth adapters by default: Add ability to disable authentication adapter #7952 (comment)
• Remove httpRequest entirely: Replace outdated http request dependency with Node 18's fetch #7589
• Change sessionToken to JWT (needs SDK support): Use JWT to authenticate (workaround inside, but looking for a proper solution) #6390
• Remove GraphQL from codebase: Remove GraphQL API from codebase #7979
• Modernize codebase, increase lint rules: Modernize Codebase #7563

Some suggestions for some nice-to-have features:

• New auth adapters + MFA: feat: Improve authentication adapter interface #8156
• expose config: Expose Parse Server config in Cloud Code #7869
• Global rate limiter: feat: Add request rate limiter based on IP address #8174
• Add dot notation by default to cloud code: feat: Add two-way binding of Parse object properties with Parse.Object.bind.key = value Parse-SDK-JS#1484
• Modernize API template: Modernize API doc template #8017
• Parallel include: Parallelize loading included objects #7981

[mtrezza]

I've added your suggestions to the list above, except:

• Use JWT to authenticate (workaround inside, but looking for a proper solution) #6390 --> could that be done without being a breaking change? if this is a more complex issue and we wouldn't want to rush this
• Expose Parse Server config in Cloud Code #7869 --> is this a breaking change? if not we can merge this anytime unrelated to the 6 release
• Modernize Codebase #7563 --> this is an internal change I assume? so maybe not breaking
• feat: Add request rate limiter based on IP address #8174 --> seems like a feature we can merge at anytime; from the discussion there I'm not sure we can turn this on by default, so maybe this will stay an optional feature anyway
• feat: Add two-way binding of Parse object properties with Parse.Object.bind.key = value Parse-SDK-JS#1484 --> is this breaking?
• Modernize API doc template #8017 --> purely cosmetic, but certainly nice-to-have with a new release

[dblythy]

The feature section are just some suggestions for features we can aim to ship by Parse Server 6, not necessarily breaking.

The problem with #7563 is that it will result in a lot of open PRs having huge merge conflicts, so internally breaking in a way. Maybe we can aim to close all PRs as complete or stale by V6, and do the overhaul of modernizing the codebase in V6.0.1, and then normal PRs can continue.

[mtrezza]

Yes, #7563 is somewhat complex; we'd want to a void 1 huge PR so we'd try to section the code base and modernize section by section. This way we would also require only selected PRs to be merged.

[mtrezza]

I haven't looked into #7979, it seems like a large effort. Given the other (required and planned) tasks we already have, it seems a bit much? I estimate that alone to take ~2-3 months getting done on the side.

[dblythy]

#7981, #8202 would be nice too.

Perhaps we can continue the discussion after V6 around #7563.

Yes, perhaps #7979 is a bit too ambitious to be released for V6.

[dblythy]

I guess the features are probably lower priority as they can always be shipped in Parse Server 6.0.1

[mtrezza]

Agree. What about #7527, could that be breaking / easier to implement as breaking?

[dblythy]

Yes, I think that is a good one. We can support it as a non-breaking change, but it's not really ideal to have 2 different startup methods, one that exposes routes before they are ready

[mtrezza]

Added to "planned".

[cbaker6]

#7440 should be considered IMO. I don’t see any PR’s open for any of the alternatives others discussed in the linked thread

[mtrezza]

Added to "tbd". Seems to require further discussion and may affect Parse client SDKs? So maybe something we should take our time with and tackle in 2023, but that's definitely an important fix and improvement.