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 (d...@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, <jc...@sangoma.com> wrote:
On Thu, Oct 1, 2020 at 3:56 PM Dan Jenkins <d...@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
--
_____________________________________________________________________
-- 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
