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

[BJ Weschke]

Four years, is indeed, really long. I do agree with this. As an example, I work with another project where the work involves some integrations with software that is in the head units of vehicles. Right now, they’re working to certify and lock down code and functionality for the 2023 vehicle model year which will hit dealer lots for the first time in just about two years from now. Once final certification occurs, in the vast majority of cases, nothing changes and the vehicles roll off the assembly line with the integration that was certified. If software that is involved in the manufacturing of vehicles can manage change risk within a two year window, it only seems reasonable that the Asterisk project should be able to do the same. 

On October 1, 2020 at 3:15:12 PM, Dan Jenkins (dan at nimblea.pe) wrote:

I'd argue two years isn't exactly quick... Especially with warnings on previous minor releases after decisions have been made. 2 years is fair - 4 is just too long. But if everyone else feels like 4 is fine then I'll stop my protest ;) 

On Thu, 1 Oct 2020, 20:09 Joshua C. Colp, <jcolp at sangoma.com> wrote:
On Thu, Oct 1, 2020 at 3:56 PM Dan Jenkins <dan at nimblea.pe> wrote:
If there was an additional message attached to minor releases, does that mean we can accelerate the steps?

On the question of why I'm opposed to 4 years? 4 years is an eternity to be in limbo - we've already seen this with chan_sip - even though its deprecated in 17, people still start using Asterisk today and use chan_sip because they don't know any better and a crap load of documentation out on the internet uses it. If the modules are deprecated, they're deprecated for a reason - kill them as quickly as reasonably possible and be done with it - it'll help everyone in the community long term. If someone disagrees with say getting rid of chan_sip then they can continue to run 17/18 or whatever - or they can take the contents of chan_sip, and apply them as a patch themselves. I'm picking on chan_sip here because its the current thing that caused these conversations in the first place.

Okay, so you'd like to see it be faster because in your opinion its better for the user base long term to force the transition quickly.

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.

--  
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
--  
_____________________________________________________________________
-- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20201001/b595029b/attachment.html>