[asterisk-dev] Reintroduce deprecated applications

[RE Kushner List Account]

Dmitry Andrianov wrote:
> Well, it is clear I'm going to be a minority on this subject but to me keeping old apps is a bad idea.
>
> 1. There will be a lot of work maintaining these. Next time you introduce some "global" change like new FOO API which should be used instead of BAR API, you will have update 2x applications. As time goes, you will be updating more and more applications which you keep for a tiny share of users.
>
> 2.Chances some old app is not properly updated with some major/API change are increased (because these are excluded from build by default). Developers needs to be careful to make sure they "turn on" the ancient apps to make sure it builds Ok. They will also need spend extra time testing these.
>
>
> To me, if there are newer and better methods of doing something, it should be Ok to deprecate the old one. I believe the current approach of doing this in Asterisk is really good. I'm talking about deprecating functionality in one release and removing in the next one. This gives users at least 2 years to update.
>
> I'm sure that every major release brings changes that will require me to update the dialplan, sometimes seriously. And by the way, other config wiles may need to be revised too. You cannot avoid that. And couple of deprecated apps would just add little changes.
>
> What I could not understand is why application does not issue deprecation warning every time it is used? People won't notice single warning in on the console. But when the warning repeats, they may pay attention long before the application disappears.
>   

It's just too hard as a user of Asterisk to upgrade, so you are creating 
islands of users using old versions which doesn't help anyone.

The way I see it there's two choices, to continue on and restore 
deprecated commands/functionality or to create intelligent upgrade 
scripts that will make it's best guess on what new function to use in a 
dialplan or other configuration files. Both are tough options, but 
something has to be done.

I think a upgrade script with extensive comments added to what was 
changed to inform the user of new functionality or commands would go 
farther than spinning wheels on ill conceived command maintenance.  At 
least the user would get more clues to what the heck happened to their 
dialplan or configuration files than finding their upgrade broke 
everything they spent years building and tuning.

Whatever is done, it has to be done intelligently. I think if you 
restore deprecated functionality it should be easier than menuselect, 
have configure look for existing configuration files and estimate which 
commands need to be restored into the code, don't add obsolete commands 
that the user doesn't use, that's the Windows problem that eventually 
created the security nightmare we see today on PCs.

One thing I've found maddening is the changing CallerID commands, I 
recently migrated a CVS pre 1.0 version of Asterisk to 1.4.18 and 
getting the Caller ID right has been my biggest problem, well that and 
the changing Set() SetVar() and other garbage like that. Adding to the 
complexity I have 1.2 servers out there that also broke CallerID, and 
the difference from pre 1.0, 1.2 and 1.4 in just caller ID commands in 
the dialplan is insane and hard to juggle in your head when you have 
multiple servers running different code sets. A migration script might 
have made this process much better and a better user experience. Having 
to migrate instead of upgrade is holding back many people, as a person 
who wrote a million lines of C code on a product I had out there years 
ago I find upgrading Asterisk daunting, I can't imagine the IT 'do it 
all' guy at a company without all the time in the world doing it.

-Ron