Ultimately whats stopping package maintainers from releasing "asterisk-full" which still has all the deprecated modules enabled.... and "asterisk" which follows the defaults? Nothing.... Other packages get released in such a way so why not asterisk? I'm 100% not qualified to talk about it because I don't use them or make them. I just think 4 years of something hanging around after its been decided to be deprecated is foolish - deprecation = "this isnt needed any more", as was stated earlier - its not a case of pjsip coming to town and chan_sip getting thrown out immediately.... the decision to deprecate it took years (and years, and years, and years) - no need to wait a further 4 years.
On Fri, Oct 2, 2020 at 8:48 AM Olle E. Johansson <o...@edvina.net> wrote: > Hi! > I like adding product management and actually removing stuff that the > company can’t keep maintaining - and don’t wan’t to. > > Compared with years ago a lot of users never bother building asterisk any > more and don’t interface with the project, > they just run “apt-get install asterisk” and they are done. We are much > more in the hands of package managers and really, > really need to interface with them to get information out. Asterisk is a > plumbing tool, much like nginx or apache. I don’t > follow those projects, haven’t built apache httpd from source for over ten > years and get my information from packaging. > > I think this has to be considered as well. > > Thanks Josh for pushing this process. > > /O > > > On 2 Oct 2020, at 00:45, Seán C McCord <ule...@gmail.com> wrote: > > > > On Thu Oct 1, 2020 at 3:07 PM EDT, Joshua C. Colp wrote: > >> I think I personally hesitate to be so aggressive because long ago the > >> project was that way. We would push to remove things faster and such, > >> and the result was upset people and complaints. Years later I still had > >> people coming up to me at AstriCon talking about that stuff and how it > screwed > >> them over. > > > > I think this is a key point which we, as developers and integrators can > easily overlook. We're being pulled in two direction: one, we must always > keep up-to-date in our implementations, and two, we must be able to work > with what the customers are willing to use. Once things are deprecated, it > is far easier to push the customer to do the right thing. Removal makes > this easier. Thus, faster deprecation and removal is better for the > integrator/developer/consultant. > > > > But we do not represent more than the barest fraction of the Asterisk > user base. The greater portion is running production workloads with very > low tolerance for either change or down-time, and are resultingly very > conservative with their upgrades and loathe to spend great effort into > managing those upgrades. > > > > If we accelerate deprecation, we may end up making the problem _worse_ > (as it used to be), where users would simply not upgrade at all, because it > was too difficult to do so. > > > > I agree that 4 years feels like an eternity to _me_, but to an operator > working with very slim margins, it is not nearly so glacial. > > > > --- > > > > Seán C McCord > > ule...@gmail.com > > PGP/GPG: https://cycoresys.com/scm.asc > > > > -- > > _____________________________________________________________________ > > -- 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 > > > -- > _____________________________________________________________________ > -- 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
-- _____________________________________________________________________ -- 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