[sr-dev] Meeting Minutes, Berlin 2009

Greger Viken Teigre gregert at teigre.com
Tue Oct 13 07:25:53 CEST 2009


I agree with Juha here.  A development release is not a concept that 
people will understand and releasing k 3.0 on a non-released sr core 
seems a bit odd to me. Isn't there a need for some kind of fixed 
reference to which version of sr core that k 3.0 is based on?! Sounds a 
bit similar to a linux distro being released using a non-released kernel 
version.

What about at least making an sr 3.0 beta that k 3.0 can be based on and 
then later move towards a release of sr 3.0 "developer/integrator edition"?
g-)

Juha Heinanen wrote:
> Jan Janak writes:
>
>  > Branch sr_3.0 is supposed to be the stable branch which, once we
>  > continue with development on the master branch, will receive bug fixes
>  > only. The same will be true for the stable kamailio branch once it is
>  > created.
>  > 
>  > Bugs found in Kamailio will be propagated to the stable sr branch and
>  > vice versa.
>  > 
>  > Basing your code on sr_3.0 is therefore safe and you should receive
>  > all bug fixes.
>
> fine, then we can release sr_3.0 at the same time when k 3.0 is
> released.  it does not mean that the release could be used by an end
> user "out of the box", but it still is a release on top of which
> software integrators (like k, ser, and other folks can base their
> releases).
>
> perhaps there will never be an "end user" release of sr, but what there
> is has to be a solid base for software integrators.  what i think still
> needs to be done is to have no fixed references to "ser" in sr_3.0 code
> or documents, but only variables that allow people to call the thing
> anything they like.  now at least sercmd reference is still fixed in
> sr_3.0.
>
> -- juha
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>   




More information about the sr-dev mailing list