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
