You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-[Publishing Major Release (Yearly Release)](#publishing-major-release-yearly-release)
42
28
-[Versioning](#versioning)
43
29
-[Code of Conduct](#code-of-conduct)
44
30
@@ -56,22 +42,6 @@ When you are ready to code, you can find more information about opening a pull r
56
42
57
43
Whether this is your first contribution or you are already an experienced contributor, the Parse Community has your back – don't hesitate to ask for help!
58
44
59
-
### Issue vs. Pull Request
60
-
61
-
An issue is required to be linked in every pull request. We understand that no-one likes to create an issue for something that appears to be a simple pull request, but here is why this is beneficial for everyone:
62
-
63
-
- An issue get more visibility than a pull request as issues can be pinned, receive bounties and it is primarily the issue list that people browse through rather than the more technical pull request list. Visibility is a key aspect so others can weigh in on issues and contribute their opinion.
64
-
- The discussion in the issue is different from the discussion in the pull request. The issue discussion is focused on the issue and how to address it, whereas the discussion in the pull request is focused on a specific implemention. An issue may even have multiple pull requests because either the issue requires multiple implementations or multiple pull requests are opened to compare and test different approaches to later decide for one.
65
-
- High-level conceptual discussions about the issue should be still available, even if a pull request is closed because its appraoch was discarded. If these discussions are in the pull request instead, they can easily become fragmented over multiple pull requests and issues, which can make it very hard to make sense of all aspects of an issue.
66
-
67
-
### Templates
68
-
69
-
You are required to use and completely fill out the templates for new issues and pull requests. We understand that no-one enjoys filling out forms, but here is why this is beneficial for everyone:
70
-
71
-
- It may take you 30 seconds longer, but will save even more time for everyone else trying to understand your issue.
72
-
- It helps to fix issues and merge pull requests faster as reviewers spend less time trying to understand your issue.
73
-
- It makes investigations easier when others try to understand your issue and code changes made even years later.
74
-
75
45
## Why Contributing?
76
46
77
47
Buy cheap, buy twice. What? No, this is not the Economics 101 class, but the same is true for contributing.
@@ -93,46 +63,6 @@ Consider the benefits you get:
93
63
94
64
Most importantly, with every contribution you improve your skills so that future contributions take even less time and you get all the benefits above for free — easy choice, right?
95
65
96
-
## Contribution FAQs
97
-
98
-
### Reviewer Role
99
-
100
-
> *Instead of writing review comments back-and-forth, why doesn't the reviewer just write the code themselves?*
101
-
102
-
A reviewer is already helping you to make a code contribution through their review. A reviewer *may* even help you to write code by actually writing it for you, but is not obliged to do so.
103
-
104
-
GitHub allows reviewers to suggest and write code changes as part of the review feedback. These code suggestions are likely to contain mistakes due to the lack of code syntax checks when writing code directly on GitHub. You should therefore always review these suggestions before accepting them, ideally in an IDE. If you merge a code suggestion and the CI then fails, take another look at the code change before asking the reviewer for help.
105
-
106
-
### Review Feedback
107
-
108
-
> *It takes too much effort to incorporate the review feedback, why why can't you just merge my pull request?*
109
-
110
-
If you are a new contributor, it's naturally a learning experience for you and therefore takes longer. We welcome contributors of any experience levels and gladly support you in getting familiar with the code base and our quality standards and contribution requirements. In return we expect you to be open to and appreciative of the reviewers' feedback.
111
-
112
-
In a large pull request, it can be a significant effort to bring it over the finish line. Luckily this is a collaborative environment and others are free to jump in to contribute to the pull request to share the effort. You can either give others access to your fork or they can open their own pull request based on your previous work.
113
-
114
-
If you are out of resources stay calm, explain your personal constraints (expertise or time) and ask for help. Wasting time by complaining about the amount of review comments will neither use your own time in a meaningful way, nor the time of others who read your complaint.
115
-
116
-
This is a collaborative enviroment in which everyone works on a common goal - to get a pull request ready for merging. Reviewers are working *with* you to get your pull request ready, *not against you*.
117
-
118
-
**❗️ Always be mindful that the reviewers' efforts are an integral part of code contribution. Their review is as important as your written code and their review time is a valuable as your coding time.**
119
-
120
-
### Merge Readiness
121
-
122
-
> *The feature already works, why do you request more changes instead of just merging my pull request?*
123
-
124
-
A feature may work for your own use case or in your own environment, but that doesn't necessarily mean that it's ready for merging. Aside from code quality and code style requirements, reviewers also review based on strategic and architectural considerations. It's often easy to just get a feature to work, but it needs to be also maintained in the future, robust therefore well tested and validated, intuitive for other developers to use, well documented, and not cause a forseeable breaking change in the near future.
125
-
126
-
### Review Validity
127
-
128
-
> *The reviewer has never worked on the issue and was never part of any previous discussion, why would I care about their opinion?*
129
-
130
-
It's contrary to an open, collaborative environment to expect others to be involved in an issue or discussion since its beginning. Such a mindset would close out any new views, which are important for a differentiated discussion.
131
-
132
-
> *The reviewer doesn't have any expertise in that matter, why would I care about their opinion?*
133
-
134
-
Your arguments must focus on the issue, not on your assumption of someone else's personal experience. We will take immediate and appropriate action in case of personal attacks, regardless of your previous contributions. Personal attacks are not permissible. If you became a victim of personal attacks, you can privately [report](https://docs.github.com/en/communities/maintaining-your-safety-on-github/reporting-abuse-or-spam) the GitHub comment to the Parse Platform PMC.
135
-
136
66
## Environment Setup
137
67
138
68
### Recommended Tools
@@ -369,8 +299,6 @@ Introducing new [Parse Server configuration][config] parameters requires the fol
369
299
370
300
## Pull Request
371
301
372
-
### Commit Message
373
-
374
302
For release automation, the title of pull requests needs to be written in a defined syntax. We loosely follow the [Conventional Commits](https://www.conventionalcommits.org) specification, which defines this syntax:
375
303
376
304
```
@@ -451,70 +379,18 @@ If the commit reverts a previous commit, use the prefix `revert:`, followed by t
451
379
This reverts commit 1234567890abcdef.
452
380
```
453
381
454
-
## Releasing
455
-
456
-
### General Considerations
457
-
458
-
- The `package-lock.json` file has to be deleted and recreated by npm from scratch in regular intervals using the `npm i` command. It is not enough to only update the file via automated security pull requests (e.g. dependabot, snyk), that can create inconsistencies between sub-dependencies of a dependency and increase the chances of vulnerabilities. The file should be recreated once every release cycle which is usually monthly.
459
-
460
382
### Major Release / Long-Term-Support
461
383
462
-
While the current major version is published on branch `release`, a Long-Term-Support (LTS) version is published on branch `release-#.x.x`, for example `release-4.x.x` for the Parse Server 4.x LTS branch.
384
+
Long-Term-Support (LTS) is provided for the previous Parse Server major version. For example, Parse Server 4.x will receive security updates until Parse Server 5.x is superseded by Parse Server 6.x and becomes the new LTS version. While the current major version is published on branch `release`, a LTS version is published on branch `release-#.x.x`, for example `release-4.x.x` for the Parse Server 4.x LTS branch.
463
385
464
-
### Preparing Release
386
+
#### Preparing Release
465
387
466
388
The following changes are done in the `alpha` branch, before publishing the last `beta` version that will eventually become the major release. This way the changes trickle naturally through all branches and code consistency is ensured among branches.
467
389
468
390
- Make sure all [deprecations](https://github.com/parse-community/parse-server/blob/alpha/DEPRECATIONS.md) are reflected in code, old code is removed and the deprecations table is updated.
469
391
- Add the future LTS branch `release-#.x.x` to the branch list in [release.config.js](https://github.com/parse-community/parse-server/blob/alpha/release.config.js) so that the branch will later be recognized for release automation.
470
392
471
-
472
-
### Publishing Release (forward-merge):
473
-
474
-
1. Create new temporary branch `build` on branch `beta`.
475
-
2. Create PR to merge `build` into `release`:
476
-
- PR title: `build: release`
477
-
- PR description: (leave empty)
478
-
3. Resolve any conflicts:
479
-
- For conflicts regarding the package version in `package.json` and `package-lock.json` it doesn't matter which version is chosen, as the version will be set by auto-release in a commit after merging. However, for both files the same version should be chosen when resolving the conflict.
480
-
4. Merge PR with a "merge commit", do not "squash and merge":
481
-
- Commit message: (use PR title)
482
-
- Description: (leave empty)
483
-
5. Wait for GitHub Action `release-automated` to finish:
484
-
- If GitHub Action fails, investigate why; manual correction may be needed.
485
-
6. Pull all remote branches into local branches.
486
-
7. Delete temporary branch `build`.
487
-
8. Create new temporary branch `build` on branch `alpha`.
488
-
9. Create PR to merge `build` into `beta`:
489
-
- PR title: `build: release`
490
-
- PR description: (leave empty)
491
-
8. Repeat steps 3-7 for PR from step 9.
492
-
493
-
### Publishing Hotfix (back-merge):
494
-
495
-
1. Create PR to merge hotfix PR into `release`:
496
-
- Merge PR following the same rules as any PR would be merged into the working branch `alpha`.
497
-
2. Wait for GitHub Action `release-automated` to finish:
498
-
- GitHub Action will fail with error `! [rejected] HEAD -> beta (non-fast-forward)`; this is expected as auto-release currently cannot fully handle back-merging; docker will not publish the new release, so this has to be done manually using the GitHub workflow `release-manual-docker` and entering the version tag that has been created by auto-release.
499
-
3. Pull all remote branches into local branches.
500
-
4. Create a new temporary branch `backmerge` on branch `release`.
501
-
5. Create PR to merge `backmerge` into `beta`:
502
-
- PR title: `refactor: <commit-summary>` where `<commit-summary>` is the commit summary of step 1. The commit type needs to be `refactor`, otherwise the commit will show in the changelog of the `release` branch, once the `beta` branch is merged into release; this would a duplicate entry because the same changelog entry has already been generated when the PR was merged into the `release` branch in step 1.
503
-
- PR description: (leave empty)
504
-
6. Resolve any conflicts:
505
-
- During back-merging, usually all changes are preserved; current changes come from the hotfix in the `release` branch, the incoming changes come from the `beta` branch usually being ahead of the `release` branch. This makes back-merging so complex and bug-prone and is the main reason why it should be avoided if possible.
506
-
7. Merge PR with "squash and merge", do not do a "merge commit":
507
-
- Commit message: (use PR title)
508
-
- Description: (leave empty)
509
-
510
-
ℹ️ Merging this PR will not trigger a release; the back-merge will not appear in changelogs of the `beta`, `alpha` branches; the back-merged fix will be an undocumented change of these branches' next releases; if necessary, the change needs to be added manually to the pre-release changelogs *after* the next pre-releases.
511
-
8. Delete temporary branch `backmerge`.
512
-
10. Create a new temporary branch `backmerge` on branch `beta`.
513
-
11. Repeat steps 4-8 to merge PR into `alpha`.
514
-
515
-
⚠️ Long-term-support branches are excluded from the processes above and handled individually as they do not have pre-releases branches and are not considered part of the current codebase anymore. It may be necessary to significantly adapt a PR for a LTS branch due to the differences in codebase and CI tests. This adaption should be done in advance before merging any related PR, especially for security fixes, as to not publish a vulnerability while it may still take significant time to adapt the fix for the older codebase of a LTS branch.
516
-
517
-
### Publishing Major Release (Yearly Release)
393
+
#### Publishing Release
518
394
519
395
1. Create LTS branch `release-#.x.x` off the latest version tag on `release` branch.
520
396
2. Create temporary branch `build-release` off branch `beta` and create a pull request with `release` as the base branch.
0 commit comments