----- On Oct 1, 2020, at 6:45 PM, 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. >
Totally agree with Seán's assessment. -- Michael Young (elguero) -- _____________________________________________________________________ -- 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
