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

Fred Posner fred at qxork.com
Thu Oct 1 14:26:31 CDT 2020


On Thu, 2020-10-01 at 20:14 +0100, Dan Jenkins 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 ;) 


I think it's a good starting point to go with 4... and then easier to
perhaps quicken that to 2 in the future. =)

-- 
Fred Posner
fred at qxork.com
https://qxork.com
Direct/SMS: +1 (336) 439-3733

Need Fred? Call Fred. 336-HEY-FRED
Matrix: @fred:matrix.lod.com

> 
> 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




More information about the asterisk-dev mailing list