Danger run resulted in 1 warning; to find out more, see the checks page.

Generated by 🚫 dangerJS

Codecov Report

Merging #7186 (5b2106e) into master (e53b6c2) will decrease coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #7186      +/-   ##
==========================================
- Coverage   94.03%   93.98%   -0.06%     
==========================================
  Files         172      172              
  Lines       12834    12834              
==========================================
- Hits        12069    12062       -7     
- Misses        765      772       +7     

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 e53b6c2...b19db81. Read the comment docs.

This is currently in draft because I couldn't find a way around the issue that a GH action in a public repo, triggered by a forked PR, apparently has no write access and therefore cannot create a PR. Still investigating...

I think we should bump the env when we do releases. We could run the CI check on a specific branch like x.x.x for the release.

I am actually not sure about this because:

• Bumping this simply requires existing PRs to rebase on master, it's not much different from any other PR that gets merged.
• We want to automate releases and reduce the effort down to 5 minutes without the requirement to touch any code or make a PR - ideally schedule and fully automate releases some time in 2022.
• If we shift more work to the time of release we increases the effort required to make a release, which is why releases are currently made only every 4 months.
• We talk about 1-2 PRs per month, currently total of 10 mins work maybe if done manually.

I am not exactly sure yet at what point into which branch we should do the bump. I think once we have the automated release concept with new branches, we'll know what's best. I suggest to keep this as is for now.

⚠️ Important change for merging PRs from Parse Server 5.0 onwards!

We are planning to release the first beta version of Parse Server 5.0 in October 2021.

If a PR contains a breaking change and is not merged before the beta release of Parse Server 5.0, it cannot be merged until the end of 2022. Instead it has to follow the Deprecation Policy and phase-in breaking changes to be merged during the course of 2022.

One of the most voiced community feedbacks was the demand for predictability in breaking changes to make it easy to upgrade Parse Server. We have made a first step towards this by introducing the Deprecation Policy in February 2021 that assists to phase-in breaking changes, giving developers time to adapt. We will follow-up with the introduction of Release Automation and a branch model that will allow breaking changes only with a new major release, scheduled for the beginning of each calendar year.

We understand that some PRs are a long time in the making and we very much appreciate your contribution. We want to make it easy for PRs that contain a breaking change and were created before the introduction of the Deprecation Policy. These PRs can be merged with a breaking change without being phased-in before the beta release of Parse Server 5.0. We are making this exception because we appreciate that this is a time of transition that requires additional effort from contributors to adapt. We encourage everyone to prepare their PRs until the end of September and account for review time and possible adaptions.

If a PR contains a breaking change and should be merged before the beta release, please mention @parse-community/server-maintenance and we will coordinate with you to merge the PR.

Thanks for your contribution and support during this transition to Parse Server release automation!