10 Oct
2009
10 Oct
'09
3:27 a.m.
To prepare for the kamailio 3.0 and sip-router 3.0 releases (according
to what we discussed at the sr meeting last week) I've created the
sr_3.0 and also enabled kamailio_3.0 (meaning that it can be created
anytime).
The "main" branches will look like:
master
|
* --- sr_3.0
|
* --- kamailio_3.0
Only fixes should be committed to sr_3.0. It should become a generic
stable branch, so it should not contain any specific changes (e.g. name
changes only for sr_3.0 a.s.o.). When we will release 3.0, we will
just create a sr_3.0_release branch and we will do any specific changes
there.
To minimize backporting/forwardporting work, if a bug is discovered on
master or on kamailio_3.0 it should be fixed in the sr_3.0 branch and
then latter sr_3.0 can be pulled (in master or kamailio_3.0):
fix
|
| (commit)
|
(merge) v (merge)
master <-------- sr_3.0 --------> kamailio_3.0
If by mistake a sr_3.0 relevant fix is committed first to another branch,
git cherry-pick -x can (and should) be used to backport it.
E.g.:
git checkout sr_3.0
git cherry-pick -x <fix_commit_id>
git pull origin sr_3.0:sr_3.0
If in any doubt, please create another branch (e.g. tmp/3.0_update
or <username>/3.0_proposed_updates) and request a pull/merge or commit
it into master.
Be especially carefully not to merge by mistake master or kamailio_3.0
into sr_3.0. It's ok only to merge sr_3.0 into master and sr_3.0 into
kamailio_3.0. Any other merge combination is bad.
The kamailio_3.0 branch is not yet created, but it can be created any time
the kamailio release managers decide it's best.
It should be created from sr_3.0. E.g.:
git checkout -b kamailio_3.0 origin/sr_3.0
git push origin HEAD:kamailio_3.0 # this command will create it
If you think we should have some commit restrictions on this branch
(IMHO to avoid mistakes is better to restrict the people who are allowed
to commit on release branches) or sr_3.0, let me know.
It would be better to avoid deleting files on the kamailio_3.0 branch.
If a file is deleted then any merge or git cherry-pick that would
involve changes to the deleted file will fail, requiring manual
patching.
Andrei