[sr-dev] release branches

Andrei Pelinescu-Onciul andrei at iptel.org
Sat Oct 10 03:27:00 CEST 2009


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



More information about the sr-dev mailing list