On 15.09.19 at 21:19 Joshua C. Colp wrote: > On Sun, Sep 15, 2019, at 2:21 AM, Michael Maier wrote:
>> BTW: I'm not really happy with the fact, that an existing LTS / stable >> version gets a new pjsip version "on the fly". From my point of view, this >> should have been >> done during a normal development cycle and not during a stable phase. > > Since support for bundled PJSIP we've actively tried to keep up to date, so > that we don't end up managing a fork and backporting a lot of patches. This > has worked well > for us and we haven't seen any problems - in fact we've gained some stability > at times. Chance - there's always a first time :-) BTW: I like the bundling of pjsip! > If this is a problem in PJSIP this would be the first time we've encountered a > regression. If people feel that we should instead lock versions then this is > certainly something we can discuss. What do others think? From a developers perspective, it's for sure better to do it as you do it like now. From a users / customers perspective, it's most probably the other way round. I don't want to have any deep changes during a LTS version (that's exactly why I'm using LTS versions). The new pjsip release should have been put to a new asterisk release, too. Asterisk 16.x was thoroughly tested and released on base of pjsip 4.8. Anybody who wants new pjsip 4.9 should consider using new Asterisk version, too. At least, I would expect a severe distinction by using a dedicated minor version (without any own asterisk changes) to detect more easily potential pjsip regressions. Thanks Michael -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
