Re: [SR-Dev] sip-router: modules & repositories

Hi, We've reached the point where we should start adding modules.

Me and Jan would like to start moving ser modules to sip-router. ser modules are particularly easy because we can move changes from ser cvs semi-automatically (only a git pull required), so we don't need to stop development on cvs. Soon we will have to add kamailio modules too,

but for kamailio it would be more painful, both because of the bigger number of changes required and because it's difficult to update from svn (so it would be better if all developers would move to git or use patches). We must decide if we use separate repositories or a branch in sip-router and we should also start thinking about the version number of the first ser and first kamailio based on sip-router. Repositories: 1. we use branches inside sip-router: master - like now, only core, tm and common modules ser_30 - master merged with ser_modules, next version of ser will come out of it kamailio_30 - same like above Disadvantages: - one big repo - people must be careful _not_ to merge ser_30 or kamailio_30 into master (that would bring all the modules into master which is not what we want) - if someone working on the ser_30 branch (for example) finds a problem in the core and wants to fix it, it has to do it on the master branch. - if the above requirement cannot be avoided and someone does a specific core change in ser_30 or k_30 (e.g. name in makefile), it should always do it in a separate commit (no commits touching both core/tm and some project specific module, instead separate commits for the common part so that they might be cherry-picked) 2. we use 3 repositories: sip-router - like now, only the common part: core, tm and common modules ser-ng - sip-router + ser modules kamailio-ng - sip-router + k modules Advantages: - 3 smaller repos - more difficult to make mistakes and merge kamailio or ser into sip-router/master Disadvantages: - 3 smaller repos :-) - same as for (1) In general whatever we can do with branches in the same repo we can with branches in different repos, so a complete kamailio-ser merge would not be affected if we use separate repos.

Version numbers: I think it would be a good idea to come up with a versioning scheme that would reflect the common part used for future ser and kamailio releases. Maybe 3.x (3 being > then both current ser and kamailio version), or mabye v.v.X , where v.v is the sip-router version (common part) and X is the project version (ser or kamailio).

What's important is to (very) quickly decide on the repository layout (because this will slow us down) and on the names for the branches or for the different repos.

Once this is decided we want to quickly make a test ser version based on sip-router and start testing it. If everything looks ok we want to start using it on iptel.org.