...
When a bug is fixed in master that should also be fixed in the next 1.9 release, that bug is to be "backported" to 1.9.x branch. The simple definition of a backport is just committing a patch (or commit) to the 1.9.x branches that was already committed to master. Commits can be backported toby
Backporting on GitHub:
The method of choice is called cherry picking.
...
| Code Block |
|---|
git cherry-pick -x de7fd1bd259ebb7ab95eb18659cbb19fd680cd3e -m 1 |
fatal: bad object errors
When cherry picking, you may some times get this error: fatal: bad object xxxxxxxxxxxxxxxxx, where the x stand for the commit hash.
...
For instance, i got the above error when cherry picking some master commits into the 1.11.x branch. Switching back to the master branch, then do git pull --rebase upstream master, before switching back to the 1.11.x branch to try again, is all i needed.
The criteria used for determining whether we should backport something is generally:
Someone has requested a backport of a feature.
Backporting the feature will not break any existing data or require any changes at an implementation level.
Backporting the feature allows us to enable something that is otherwise not possible or fixes behaviour that is obviously a bug.
It seems unlikely that backporting the feature will require any changes to any modules, other than to take advantage of any new functionality.
The goal is to ensure that if someone is already running a version and we release a maintenance version of it, they only have to upgrade the version of core and everything else will continue working, while still allowing us to add new features to an existing version when those features are useful (so, a much looser interpretation of SemVer than we use on the frontend).