[asterisk-dev] Module Deprecation, Default Not Building, and Removal

[Michael L. Young]

----- On Oct 1, 2020, at 6:45 PM, Seán C McCord ulexus at 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)