[asterisk-dev] Memory leak since Asterisk 16.5.x / pjsip

[Corey Farrell]

Updating pjproject does take less time/effort than maintaining a fork 
for the many years of an LTS release.  That reduced effort isn't just 
free time to developers, the time is instead spent working on 
enhancements and bug fixes.  Maintaining a fork would prevent users from 
getting important upstream bug fixes and would introduce risk of 
regressions caused by the fork itself.  So my vote is that pjsip version 
bumps should not be held back.  I'm also not in favor of creating 
separate releases for pjsip version bumps, this takes time that I feel 
can/should be spent on other tasks.

One thing I think Asterisk can improve is to always make sure that any 
pjsip version bump is prominently mentioned in release notes, probably a 
note in the CHANGES and/or UPGRADE files.  This would let people who use 
bundled pjproject of potentially major changes.  It would also tell 
users of non-bundled pjproject that they should upgrade their own 
libraries as the older version is no longer tested.

On 9/16/19 1:06 PM, Michael Maier wrote:
> 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
>