tonyair/silverstripe-framework
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-framework synced 2024-10-01 21:58:51 +02:00
Code Issues Projects Releases Wiki Activity

Better definition of "pre-release" branch in docs

Browse Source
This commit is contained in:
Ingo Schommer 2013-10-22 16:19:49 +02:00
parent 927dd6c606
commit fad8926785
1 changed files with 5 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/en/misc/contributing/code.md
View File

@ -28,7 +28,11 @@ If you're familiar with it, here's the short version of what you need to know. O
* **Squash your commits, so that each commit addresses a single issue.** After you rebase your work on top of the upstream branch, you can squash multiple commits into one. Say, for instance, you've got three commits in related to Issue #100. Squash all three into one with the message "Issue #100 Description of the issue here." We won't accept pull requests for multiple commits related to a single issue; it's up to you to squash and clean your commit tree. (Remember, if you squash commits you've already pushed to GitHub, you won't be able to push that same branch again. Create a new local branch, squash, and push the new squashed branch.) * **Squash your commits, so that each commit addresses a single issue.** After you rebase your work on top of the upstream branch, you can squash multiple commits into one. Say, for instance, you've got three commits in related to Issue #100. Squash all three into one with the message "Issue #100 Description of the issue here." We won't accept pull requests for multiple commits related to a single issue; it's up to you to squash and clean your commit tree. (Remember, if you squash commits you've already pushed to GitHub, you won't be able to push that same branch again. Create a new local branch, squash, and push the new squashed branch.)
* **Choose the correct branch**: Most pull requests should go against the *pre-release branch*, only critical bugfixes against the *release branch*. If you're changing an API or introducing a major feature, the pull request should go against `master`. Depending on where in the release process the pre-release branch is. If its in beta, the room for API changes is very small (read more about our [release process](/misc/release-process)). * **Choose the correct branch**: Most pull requests should go against the *pre-release branch*, only
critical bugfixes against the *release branch*. A *pre-release branch* is any branch which hasn't
received a stable [minor release](/misc/release-process#minor-releases), most commonly the master
branch. If you're changing an API or introducing a major feature, the pull request should go against a *pre-release branch*. If this branch already had a beta release, the room
for API changes is very small (read more about our [release process](/misc/release-process)).
## Step-by-step: From forking to sending the pull request ## Step-by-step: From forking to sending the pull request