[sr-dev] release branches

[Daniel-Constantin Mierla]

On 11.10.2009 11:40 Uhr, Andrei Pelinescu-Onciul wrote:
> On Oct 11, 2009 at 10:54, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
>   
>> 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.
>>     
>
> There wouldn't be any difference from git's point of view.
> The access policy is based on matching a regular expression on the
> branch name, so it wouldn't make any difference there either.
> The only problem is cvs access: branches containing '/'  cannot be
> exported to cvs, so if someone is using cvs to access the sip-router
> repository, they wouldn't be able to access these branches.
>
> However it might be a little confusing
> (e.g. git checkout -b kamailio/3.0 origin/kamailio/3.0
>        git push origin kamailio/3.0:kamailio/3.0).
>
> Let me know if you want to change it.
>   

it is ok then. I thought there might be a different path on the source 
tree, with some benefits in handling.

Cheers,
Daniel


>> 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.
>>     
>
> Yes, it would be best to push all common changes to sr_3.0 first
> (less work for everybody).
>
> Just to clarify a bit: the problems will be only for people maintaining
> the kamailio_3.0 branch, which will not be able to get changes from
> sr_3.0 by merging, if the changes "touch" a file which was deleted on
> the kamailio_3.0 branch => you will have to do manual patching in this
> cases (or if the commit touching the deleted files can be clearly
> separated, you could use git cherry-pick -x  <the_other_commits>).
> Adding new files, moving and renaming won't introduce any problems
> (merge tracks them in most cases with a few exceptions, like replacing a
> file with a directory with the same name and then moving the file in
> that directory).
>
> Irrespective of what changes happen or not in the kamailio branch, one
> should never attempt to merge it back to sr_3.0 or master
> (sr_3.0 to kamailio_3.0 is ok, kamailio_3.0 to sr_3.0 is _not_ since we
>  do not want k specific changes in sr_3.0).
>
>   

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