On Mon, Sep 16, 2019 at 12:45 PM Corey Farrell <[email protected]> wrote:
> 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. > I think we normally do that unless we missed one by accident. I also do a blog post with a title like 'PJproject x.x qualified for use by Asterisk" > > 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 > > > > -- > _____________________________________________________________________ > -- 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 -- *George Joseph* Digium - A Sangoma Company | Software Developer | Software Engineering 445 Jan Davis Drive NW - Huntsville, AL 35806 - US direct/fax: +1 256 428 6012 Check us out at: https://digium.com ยท https://sangoma.com
-- _____________________________________________________________________ -- 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
