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
--
_____________________________________________________________________
-- 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
