13 Oct
2009
13 Oct
'09
8:25 a.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev