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

Reply via email to