[sr-dev] release branches

[Daniel-Constantin Mierla]

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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>   

-- 
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/