tyler.durden/notepad-plus-plus
1
0
Fork 0
mirror of https://github.com/notepad-plus-plus/notepad-plus-plus.git synced 2025-07-19 20:04:38 +02:00
Code Issues Packages Projects Releases Wiki Activity

Add translation PR rule for the version number

Browse Source
This commit is contained in:
Don HO 2025-06-15 17:25:41 +02:00 committed by GitHub
parent ccd155d605
commit a758c35b7a
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 9 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
CONTRIBUTING.md
View File

@ -30,14 +30,15 @@ Opening an issue beforehand allows the administrators and the community to discu
2. Create a new branch for each PR. **Make sure your branch name wasn't used before** - you can add date (for example `patch3_20200528`) to ensure its uniqueness.
3. Single feature or bug-fix per PR.
4. Create a PR with a single commit to make the review process easier.
5. Make your modification compact - don't reformat source code in your request. It makes code review more difficult.
6. PR of reformatting (changing of ws/TAB, line endings or coding style) of source code won't be accepted. Use issue trackers for your request instead.
7. Typo fixing and code refactoring won't be accepted - please create issues with title started with `TYPO` to request the changing.
8. The PR for the enhancement of Function List parser should also include unit test. Please refer [here](https://npp-user-manual.org/docs/function-list/#contribute-your-new-or-enhanced-parser-rule-to-the-notepad-codebase) for more information.
9. Address the review change requests by pushing new commits to the same PR. Avoid amending a commit and then force pushing it. All the PR commits are squashed before merging to the main branch.
10. When creating new PR, try to base it on latest master.
11. Normally you don't need to merge `upstream/master` (using git or via github sync), if your PR is based on older `upstream/master`. If you need to base it on latest `master` (e.g. to check and fix merge conflict), use commands `git fetch upstream` to get latest `master` and then `git rebase upstream/master` to rebase it onto this latest `upstream/master`.
12. Finally, please test your pull requests, at least once.
5. For the PR of translation, don't guess or use the next version number. Use the current version number instead.
6. Make your modification compact - don't reformat source code in your request. It makes code review more difficult.
7. PR of reformatting (changing of ws/TAB, line endings or coding style) of source code won't be accepted. Use issue trackers for your request instead.
8. Typo fixing and code refactoring won't be accepted - please create issues with title started with `TYPO` to request the changing.
9. The PR for the enhancement of Function List parser should also include unit test. Please refer [here](https://npp-user-manual.org/docs/function-list/#contribute-your-new-or-enhanced-parser-rule-to-the-notepad-codebase) for more information.
10. Address the review change requests by pushing new commits to the same PR. Avoid amending a commit and then force pushing it. All the PR commits are squashed before merging to the main branch.
11. When creating new PR, try to base it on latest master.
12. Normally you don't need to merge `upstream/master` (using git or via github sync), if your PR is based on older `upstream/master`. If you need to base it on latest `master` (e.g. to check and fix merge conflict), use commands `git fetch upstream` to get latest `master` and then `git rebase upstream/master` to rebase it onto this latest `upstream/master`.
13. Finally, please test your pull requests, at least once.
In short: The easier the code review is, the better the chance your pull request will get accepted.