<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 16, 2019 at 12:45 PM Corey Farrell <<a href="mailto:git@cfware.com">git@cfware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Updating pjproject does take less time/effort than maintaining a fork <br>
for the many years of an LTS release.  That reduced effort isn't just <br>
free time to developers, the time is instead spent working on <br>
enhancements and bug fixes.  Maintaining a fork would prevent users from <br>
getting important upstream bug fixes and would introduce risk of <br>
regressions caused by the fork itself.  So my vote is that pjsip version <br>
bumps should not be held back.  I'm also not in favor of creating <br>
separate releases for pjsip version bumps, this takes time that I feel <br>
can/should be spent on other tasks.<br>
<br>
One thing I think Asterisk can improve is to always make sure that any <br>
pjsip version bump is prominently mentioned in release notes, probably a <br>
note in the CHANGES and/or UPGRADE files.  This would let people who use <br>
bundled pjproject of potentially major changes.  It would also tell <br>
users of non-bundled pjproject that they should upgrade their own <br>
libraries as the older version is no longer tested.<br></blockquote><div><br></div><div>I think we normally do that unless we missed one by accident.</div><div>I also do a blog post with a title like 'PJproject x.x qualified for use by Asterisk"</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On 9/16/19 1:06 PM, Michael Maier wrote:<br>
> On 15.09.19 at 21:19 Joshua C. Colp wrote:<br>
>> On Sun, Sep 15, 2019, at 2:21 AM, Michael Maier wrote:<br>
>>> 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<br>
>>> done during a normal development cycle and not during a stable phase.<br>
>> 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<br>
>> for us and we haven't seen any problems - in fact we've gained some stability at times.<br>
> Chance - there's always a first time :-)<br>
> BTW: I like the bundling of pjsip!<br>
><br>
>> If this is a problem in PJSIP this would be the first time we've encountered a<br>
>> regression. If people feel that we should instead lock versions then this is certainly something we can discuss. What do others think?<br>
>  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<br>
> 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.<br>
> 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.<br>
><br>
> 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.<br>
><br>
><br>
> Thanks<br>
> Michael<br>
><br>
<br>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr" style="font-size:12.8px"><b style="font-family:arial,helvetica,sans-serif;font-size:12.8px">George Joseph</b><br></div><div dir="ltr"><div style="font-size:12.8px"><font face="arial, helvetica, sans-serif" size="1">Digium - A Sangoma Company | Software Developer | Software Engineering</font></div><font size="1">445 Jan Davis Drive NW - Huntsville, AL 35806 - US</font></div><div dir="ltr"><font size="1">direct/fax: +1 256 428 6012</font><div style="font-size:12.8px"><font face="arial, helvetica, sans-serif" size="1">Check us out at: <a href="https://digium.com/" style="color:rgb(17,85,204)" target="_blank">https://digium.com</a> · <a href="https://sangoma.com/" style="color:rgb(17,85,204)" target="_blank">https://sangoma.com</a></font></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><img src="https://www.digium.com/sites/digium/themes/digium/logo.png" width="96" height="60"></div></div></div></div></div></div></div>