docs: Clarify wording in DEPRECATIONS table

[mtrezza]

Summary by CodeRabbit

• Documentation
  • Updated deprecation documentation terminology to reflect that deprecated features will be "changed" rather than "removed" following the deprecation period.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[parse-github-assistant]

🚀 Thanks for opening this pull request!

[coderabbitai]

📝 Walkthrough

Walkthrough

Documentation update to DEPRECATIONS.md replacing removal-centric terminology with change-centric language throughout the deprecation table, including column names, status descriptions, and metadata tags.

Changes

Cohort / File(s)	Summary
Deprecation documentation terminology update DEPRECATIONS.md	Updated all removal-related terminology to change-related terminology: "Planned Removal" → "Planned Change", "[i_removal]" → "[i_change]", "removed" → "changed" status labels, and corresponding description text.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

• File scope: Single documentation file with consistent, repetitive terminology replacements across the deprecation table
• Change pattern: Homogeneous updates applying the same conceptual change (removal → change) throughout the document
• Complexity: No logic, functional code, or structural changes; pure documentation terminology alignment

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The pull request description is missing entirely. Required sections like Issue, Approach, and Tasks from the template are not filled out.	Add a description following the repository template, including the linked issue, approach explanation, and relevant task checkboxes.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately reflects the main change—clarifying deprecation documentation wording in the DEPRECATIONS table.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b717ea3 and 2899215.

📒 Files selected for processing (1)

• DEPRECATIONS.md (1 hunks)

🧰 Additional context used

🧠 Learnings (5)

📓 Common learnings

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
Learning: When reviewing Parse Server PRs that add new features, always check whether the feature is documented in the README.md file, though for new Parse Server options this is optional rather than required.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-12-02T08:00:20.138Z
Learning: For Parse Server 9 release (PR #9938 and related), the parse/push-adapter dependency must be upgraded to version >= 8.0.0, not 7.0.0. Version 8.x drops support for Node 18.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-17T15:02:48.786Z
Learning: For Parse Server PRs, always suggest an Angular commit convention PR title that would make a meaningful changelog entry for developers. Update the PR title suggestion on every commit. The format should be: type(scope): description. Common types include feat, fix, perf, refactor, docs, test, chore. The scope should identify the subsystem (e.g., graphql, rest, push, security). The description should be action-oriented and clearly convey the change's impact to developers.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-17T15:02:24.824Z
Learning: For Parse Server PRs, always suggest an Angular-style PR title that would make a meaningful changelog entry for developers. Update the PR title suggestion with every new commit to the PR.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-12-02T08:00:08.440Z
Learning: For Parse Server 9 release preparation, the parse/push-adapter dependency should be upgraded to version >= 8.0.0, not 7.x, as version 8.x is required despite dropping Node 18 support (which aligns with Parse Server 9's removal of EOL Node versions).

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
Learning: For new Parse Server options, verify that the option is documented in src/Options/index.js and that npm run definitions has been executed to reflect changes in src/Options/docs.js and src/Options/Definitions.js. README.md documentation is a bonus but not required for new options.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-12-02T06:55:53.808Z
Learning: When reviewing Parse Server PRs that add or modify Parse Server options, always verify that changes are properly reflected in three files: src/Options/index.js (where changes originate), src/Options/Definitions.js, and src/Options/docs.js. The correct workflow is: make changes in index.js first, then run `npm run definitions` to automatically replicate the changes to Definitions.js and docs.js.

📚 Learning: 2025-12-02T08:00:08.440Z

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-12-02T08:00:08.440Z
Learning: For Parse Server 9 release preparation, the parse/push-adapter dependency should be upgraded to version >= 8.0.0, not 7.x, as version 8.x is required despite dropping Node 18 support (which aligns with Parse Server 9's removal of EOL Node versions).

Applied to files:

• DEPRECATIONS.md

📚 Learning: 2025-12-02T08:00:20.138Z

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-12-02T08:00:20.138Z
Learning: For Parse Server 9 release (PR #9938 and related), the parse/push-adapter dependency must be upgraded to version >= 8.0.0, not 7.0.0. Version 8.x drops support for Node 18.

Applied to files:

• DEPRECATIONS.md

📚 Learning: 2025-11-08T13:46:04.940Z

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
Learning: When reviewing Parse Server PRs that add new features, always check whether the feature is documented in the README.md file, though for new Parse Server options this is optional rather than required.

Applied to files:

• DEPRECATIONS.md

📚 Learning: 2025-11-08T13:46:04.940Z

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
Learning: For new Parse Server options, verify that the option is documented in src/Options/index.js and that npm run definitions has been executed to reflect changes in src/Options/docs.js and src/Options/Definitions.js. README.md documentation is a bonus but not required for new options.

Applied to files:

• DEPRECATIONS.md

🪛 markdownlint-cli2 (0.18.1)

DEPRECATIONS.md

21-21: Link fragments should be valid

(MD051, link-fragments)

---

22-22: Link fragments should be valid

(MD051, link-fragments)

---

23-23: Link fragments should be valid

(MD051, link-fragments)

🔇 Additional comments (2)

DEPRECATIONS.md (2)

3-23: Excellent clarity improvement on deprecation terminology.

The terminology shift from "removed" to "changed" is applied consistently across the document. The updated wording better reflects a more nuanced deprecation model where features are transformed rather than deleted, giving developers clearer expectations about the nature of breaking changes. All 13 deprecation entries are updated with matching status values.

---

21-23: Verify markdown linting warnings about link fragments.

Static analysis flags lines 21–23 with MD051 (link-fragments) warnings. The footnote format [reference]: ## "text" appears to be a custom markdown convention (possibly for tooltips), as it deviates from standard markdown link reference syntax. Notably, line 21 (which wasn't changed) is also flagged, suggesting either a pre-existing issue or a false positive.

Please confirm:

1. Is this custom footnote format intentional and used consistently across the project's documentation?
2. Are these linting warnings acceptable, or should the format be adjusted to comply with standard markdown link syntax?

If this is a known pattern in the project, you may safely ignore the lint warnings. Otherwise, consider updating the footnote format to standard markdown:

-[i_change]: ## "The version and date of the planned change."
+[i_change]: #i-change "The version and date of the planned change."

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[parseplatformorg]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[parseplatformorg]

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

[parseplatformorg]

🎉 This change has been released in version 9.1.0