The Camel 2.x branches are here:
...
What should be merged
The idea is to be able to apply bug fixes and backwards compatible improvements and new features to our Camel maintenance branches (for example 2.10.x and 2.9.x) while leaving NONE NON backwards compatible changes on the trunk. The idea is to give our users the best experience possible on any supported branch as long we have 100% backward compatibility on patch versions.
What should be considered as NOT backwards compatible
- change in our public API
- change in the behavior of a component
- change in a default value of a component
Changes which SHOULD apply to maintenance branches
- Bug fix which is backwards compatible
- Smaller improvement which is backwards compatible
- Small new feature which is backwards compatible
- Third party dependency updates on micro/patch versions (3rd digit)
Changes which MUST NOT be applied to maintenance branches
- Bug fix which is NOT backwards compatible
- Improvement which is NOT backwards compatible
- New feature which is NOT backwards compatible
- Non trivial refactoring
Changes which MAY be applied to maintenance branches
For all the changes in this category we have to be especially carefully to not break backwards compatibly. Again, the goal is to be 100% backward compatibility on patch versions. Take extra time to review and test your change. Even better, send a \ [HEADS UP\] on the dev@ mailing list and ask for assistance/review. Wiki Markup
- Non trivial improvement which is backwards compatible
- Non trivial new feature which is backwards compatible
- Third party dependency updates on major or minor versions (1st and 2nd digit)
- Trivial refactoring
Who should do the merge
It is preferred that the committer who applied the change to trunk also merge it back to the maintenance branches. He knows best whether this fix should go into the maintenance branche(s) or not and he can also make sure the WIKI pages are up to date. However, other people may also merge fixes back if they require it there. In that case, those people should pay extra attention to make sure the changes meet the above criteria.
...
2. Check out the branch
Code Block |
---|
svn co https://svn.apache.org/repos/asf/camel/branches/camel-2.8.x camel-2.8.x
|
3. In camel-2.8.x directory, you can get a list of commits available from the trunk
Code Block |
---|
svnmerge.py avail
|
4. Merge your commit by running
Code Block |
---|
svnmerge.py merge -r 123456
|
...
6. Commit it by running
Code Block |
---|
svn ci -F svnmerge-commit-message.txt
|
...
Using DoMerges tool
If you look in:
...
there is a DoMerges.java
file in there that you can compile and run from a fixes branch checkout.
It pretty much walks you through the entire process of backporting fixes.
...
To run the file do, from the directory with the branch.
Code Block |
---|
java DoMerges
|
You need svnmerge.py
to be runnable from the command line.
There is a compiled .class of the DoMerges attached to this wiki page you can download. However its easy to compile
the source file, as it has no other dependencies so its all plain
Code Block |
---|
javac DoMerges.java
|
Using git
...
Create a local branch from the remote tracking branch (e.g. camel-2.8.x)
Code Block |
---|
git checkout -b camel-2.8.x remotes/camel-2.8.x
|
or switch into the existing branch
Code Block |
---|
git checkout camel-2.8.x
|
To merge one revision (e.g. 1176050) into this branch, run
Code Block |
---|
git cherry-pick 1176050
|
This will merge and commit the changes into your local git repository.
Info | ||||
---|---|---|---|---|
| ||||
If you have to combine multiple revisions into one commit, run
for each revision (the -n options prevents the commit after the merge). Afterwards you have to run
to commit all the changes with one commit into your local git repository. |
Run
Code Block |
---|
git svn dcommit
|
to push your local changes into the Apache SVN repository.
...
Tip | ||
---|---|---|
| ||
There is a number of Git Graphical Tools which can be used as well for backporting fixes. For example GitX or GitTower for Mac users. |
Closing github PRs
The PRs at github is only automatic closed if the commit log has words like closes, fixes etc. And therefore we often ask the author of the PR to close the PR after it has been merged, or rejected. However the author may not see the notification or he/she does not react. So the Camel team can force close the PRs using an empty git message:
Code Block |
---|
git commit --allow-empty -m "This closes #xxxx" |
You can then include multiple PRs etc. This closes #123. This closes #456.