[asterisk-dev] Reintroduce deprecated applications

Dmitry Andrianov dimas at dataart.com
Tue May 13 09:04:31 CDT 2008

While I agree with you that upgrade script could be very useful, I do not really see how one can make such a script. For many changes you have nothing to do but to report user "Sorry, no way, you have to rewrite this" or "Pay attention to this piece of dialplan - we have somehow changed the application". So still lots of manual editing. Take a look at 1.4's UPGRADE.txt file. How many of these can be automated?

Also keep in mind there are more languages to express dialplan - like AEL or LUA. So you will need to create upgrade script for each of them. It going to be a nightmare.

And last but not least, there are changes which do not related to dialplan but still affect Asterisk behavior significantly. So I'm not sure how these can be handled with upgrade script.

My personal opinion is that any upgrade from 1.2 to 1.4 is a lot of manual work which you cannot avoid anyway. And you must be prepared - you rolling it out in test environment first. It is one time job anyway - you are not going to upgrade your system every day. What Asterisk can do to help you is to provide you a simple regexp-based script which just indicates you places in your dialplan / config which will definitely need attention (just indicating, not changing anything). I would also make every deprecated option/application issue a warning on each use (as opposed to first use). And also, I would color-coded "core show application ABC" and stuff like that to make sure the fact that app is deprecated is really clearly visible.

I would possibly also make deprecated apps stay one version longer before being killed completely. So something deprecated in 1.2 only goes away in 1.6. Maybe.

But I honestly do not believe that keeping couple of old apps is going to change someone's upgrade time considerably. Taking into account number of other changes UPGRADE.txt file - no.. do not believe it.

Dmitry Andrianov

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of RE Kushner List Account
Sent: Tuesday, May 13, 2008 5:24 PM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Reintroduce deprecated applications

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.


--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:

More information about the asterisk-dev mailing list