[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