Hello,
On 10.10.2009 3:27 Uhr, Andrei Pelinescu-Onciul wrote:
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
thanks!
I was wondering about possibility to use something like "kamailio/3.0" in the same way of "tmp/xyz".
Not sure if is better or whether is actually any difference in such naming policy of git branches.
For K 3.0 we may need to add new files, rename files, remove some modules, etc. which I understood will create troubles in merging. I think by pushing to sr_3.0 first we ensure portability to master in an easy way.
Cheers, Daniel
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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev