Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Updating command examples with M5 #180

Merged
merged 2 commits into from
Jan 15, 2024
Merged

Updating command examples with M5 #180

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4101434
Updating command examples with M5
escopecz Jan 15, 2024
5db4c4e
Apply suggestions from code review
escopecz Jan 15, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
14 changes: 7 additions & 7 deletions pages/15.contributing/02.developer/01.Code/02.Pull requests/docs.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -96,10 +96,10 @@ b = current minor release (e.g. 4.4 in 4.4.5)
c = future major release (e.g. 5 in 5.0)

* All PRs are made against the c.x branch in the first instance (e.g. 5.x)
* If the PR should be merged in an earlier release than the next major release of Mautic, duplicate the PR against the relevant a.b branch for bug fixes (e.g. 4.4), or a.x branch for features and enhacements (e.g. 4.x).
* If the PR should be merged in an earlier release than the next major release of Mautic, duplicate the PR against the relevant a.b branch for bug fixes (e.g. 5.0), or a.x branch for features and enhancements (e.g. 5.x).
* Backwards compatibility breaking changes can only be released in a major version, so they should only ever be made against the c.x branch (e.g. 5.x)

The exception to this rule is if the last feature release (e.g. 4.4) has already been made, then all features would be made against the c.x branch, rather than the 4.x branch. This is usually made clear in release notes, but if you're not sure, please ask in #t-product on Slack.
The exception to this rule is if the last feature release (e.g. 5.4) has already been made, then all features would be made against the c.x branch (e.g. 6.x), rather than the 5.x branch. This is usually made clear in release notes, but if you're not sure, please ask in #t-product on Slack.

As an example, if Mautic just released a 4.0.0 version of Mautic, the following would apply:

Expand Down Expand Up @@ -139,19 +139,19 @@ composer install
Each time you want to work on a PR for a bug or on an enhancement, create a topic branch from the relevant base branch:

```
git checkout -b BRANCH_NAME 4.x
git checkout -b BRANCH_NAME 5.x
```

Or, if you want to provide a bug fix for the `4.4` branch, first track the remote `4.4` branch locally:
Or, if you want to provide a bug fix for the `5.0` branch, first track the remote `5.0` branch locally:

```
git checkout -t origin/4.4
git checkout -t origin/5.0
```

Then create a new branch off the `4.4` branch to work on the bug fix:
Then create a new branch off the `5.0` branch to work on the bug fix:

```
git checkout -b BRANCH_NAME 4.4
git checkout -b BRANCH_NAME 5.0
```

>>>>>> Use a descriptive name for your branch - for example issue_XXX where XXX is the issue number is a good convention for bug fixes.
Expand Down