-
Notifications
You must be signed in to change notification settings - Fork 0
Home
This repo is a public fork of the recurly-client-php library. The master branch should be kept in sync using the guide at https://help.github.com/articles/syncing-a-fork/. All other branches from the recurly-client-php library have been intentionally removed.
The default branch of this repo should be set to a branch that represents the latest tagged release from Recurly with our patches applied.
Releases follow semantic versioning and any patched releases have the -patch suffix.
Follow the guide at https://help.github.com/articles/syncing-a-fork/. You should have a new remote named upstream that points to git@github.com:recurly/recurly-client-php.git
Checkout a new branch based off of the branch/tag/SHA to which the patch should apply. This is generally going to be a specific release tag from Recurly. The new branch name should be prefixed with patches/ and follow the naming convention <issue>-<shortdescription>-<release>.
For example, if you created issue #300 in the recurly issue queue and you wanted to patch against the 2.4.1 tagged release, you would name your new branch patches/300-short-description-of-issue-2.4.1.
Here's a one-liner example:
git checkout -b patches/300-short-description-of-issue-2.4.1 upstream/2.4.1
Push your new branch to our repo and create a pull request in the official Recurly PHP Client repo. Be kind and helpful.
If Recurly accepts the pull request and creates a new release, move on to managing patches and releases.
If you need to get your patch live ASAP, then apply your patch to this repo's current default branch (e.g. releases/2.4.1-patch), and create a new tag with an incremented semantic number if necessary (e.g. 2.4.1-patch2). The branch should never have a semantic, incremented number at the end of it. Use tags to manage the releases. This will make the lives of anyone that uses Composer easier.
When Recurly releases a new version of their library, you will have to checkout a new branch for the tagged release and push it to our repo. Here's the one-liner for release 2.4.1:
git checkout -b releases/2.4.1 upstream/2.4.1 && git push origin releases/2.4.1
If we have patches that need to be applied, you will need to checkout a new branch from the release branch you just made. Here's the one-liner:
git checkout -b releases/2.4.1-patch upstream/2.4.1 && git push origin releases/2.4.1-patch
NOTE: Both the 'released' branch and the 'released patch' branch should be pushed to our repo.
Now you have to apply the patches. For each branch that starts with patches/, try to merge into your current branch. It should look something like this:
git merge origin/patches/126-psr3-logger-for-v2.41
One of three things will happen:
- The merge will be successful.
- The merge will have conflicts, and you will have to fix them.
- The merge will be unnessary (because the patch is already part of the current release form Recurly)
Once all of the required patches have been applied and tested, push the 'release-patch' branch up to our repo.
git push origin releases/2.4.1-patch
Do not make a pull request to the official recurly library with this branch.
At this point, you can either create a 2.4.1-patch2 tag in the Github interface or use git. We do this to make life easier for projects that use Composer.
New patches that need to be applied to releases/2.4.1-patch should be applied to the branch, pushed, and tagged according to semantic versioning (e.g. 2.4.1-patch2, 2.4.1-patch3, etc.)