[asterisk-dev] Proposed removal of deprecated modules in Asterisk 13 (cdr_sqlite, chan_gtalk, chan_jingle, res_jabber, chan_h323, app_readfile, app_dahdibarge, app_setcallerid, app_saycountpl)

[Matthew Jordan]

On Tue, Jul 1, 2014 at 3:42 PM, Corey Farrell <git at cfware.com> wrote:
>
> Some more candidates for removal and the revision they were deprecated:
> DBDel application - r30241
> MailboxExists application - r43659 (the replacement was
> deprecated/replaced almost 3 years ago)
> voicemail.conf options maxmessage / minmessage - r49075
> ImportVar application - r76703
> ast_device_state_changed() / ast_device_state_changed_literal() - r79027
> logger.conf option rotatetimestamp - r81277
> ast_channel_datastore_alloc() / ast_channel_datastore_free() - r135680
> devstate2str() / ast_channel_cmpwhentohangup() /
> ast_channel_setwhentohangup() - r159818
>
> These aren't a very big deal to leave in place, but they're clutter
> and have all been deprecated for over 5 years.  If we leave deprecated
> items in place forever people will expect that for everything.  Some
> of the stuff that is deprecated C functions is a simple matter of
> cleaning the symbol exports.  Revision numbers are based on svn blame
> from /branches/11.


Agree on all of the above.

I went ahead and threw the first round of these up on review board -
https://reviewboard.asterisk.org/r/3698/. I think it'd be good to go
through these and remove them in another round before the feature
freeze.

>
>
> While we are making serious suggestions, will app_macro ever become
> officially deprecated?  It's marked as replaced by app_stack, but that
> tells people "You have another option instead of this."  Deprecating
> would tell people "You should not use this, use app_stack instead."
>

We actually did announce that in Asterisk 11 - at least in the CHANGES
and on the wiki [1]. It would probably be worthwhile to add a
deprecation notice to the Macro applications as well.

Removing macro, on the other hand, is a bit tricky, for a few reasons:

(1) There are core changes that should be made when this occurs, such
as removal of the macrocontext/macroexten from the ast_channel
structure. These properties are used in a lot of places, and some care
should be taken when ripping them out.

(2) A lot of people still use macros. A _lot_. FreePBX, for one, still
uses macros extensively. We should probably make an effort in
advertising that macros are deprecated, but wait a bit longer to
remove them. While our policy is two release cycles, I think being
pragmatic on this one - particularly when we have not been very good
about removing deprecated items in the past - is probably warranted.

[1] https://wiki.asterisk.org/wiki/display/AST/New+in+11

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org