Hi Josh, Thanks for this! I have a question regarding this line in your email.
These changes allow the information regarding when a module was deprecated and when it will be removed to be communicated to users in earlier branches. Does this mean that app_foo being marked as deprecated in master (19 isnt cut yet) will appear in earlier versions of Asterisk too? ie a new security release of 16 gets released and the newly deprecated in master app_foo will get applied as a warning to 16? I didnt see that explained in the wiki article but I think thats how we talked about it working a while back Thanks! Dan On Thu, Mar 11, 2021 at 3:15 PM Joshua C. Colp <jc...@digium.com> wrote: > Kia ora, > > It's been some time since our discussion last year regarding module > deprecation but over the past few weeks and days I've been working out the > details of putting it into action. To that end I've created a wiki page[1] > describing the policy and providing step by step instructions for module > deprecation and removal. These instructions cover the discussion, JIRA, and > code sides. I have also put up reviews[2][3][4][5] for the technical side > of things. These changes allow the information regarding when a module was > deprecated and when it will be removed to be communicated to users in > earlier branches. The information is displayed both in menuselect but also > appears at Asterisk startup. The changes have not yet been merged but I'll > be working to take care of any comments and ensure they are. Finally I've > audited the tree and created a wiki page[6] listing modules that can be > removed for 19. > > To those reading this wiki page you may note a few things: > > The app_macro module is tentatively scheduled for 19, but I have an open > dialog with the FreePBX team at Sangoma to make sure this is possible as > they are a consumer of the app_macro module currently. Depending on > discussions and information this could get pushed to 21 but I will try for > 19. > > I have also slated res_monitor for removal in 21 instead of 19. This > module still seems to have a loyal following so I believe setting it to > defaultenabled no and giving further notification of removal is the most > reasonable course of action for it so we can determine if truly removing it > is the best option. > > Finally I have also added some proposed module deprecations for 19. If > anyone has any concern with these we can start the discussions, and this > includes others proposing deprecation of additional modules. > > I think that's about it for module deprecation for now but in > approximately 2-4 weeks after things have settled I will also be writing a > blog post about this subject and posting it in the various user focused > places: @AsteriskDev Twitter, asterisk-users mailing list, > https://community.asterisk.org/ so that Asterisk users are also aware of > this (albeit from a higher level perspective). > > I think that's about it! Have a super day all. > > Cheers, > > [1] https://wiki.asterisk.org/wiki/display/AST/Module+Deprecation > [2] https://gerrit.asterisk.org/c/asterisk/+/15599 > [3] https://gerrit.asterisk.org/c/asterisk/+/15624 > [4] https://gerrit.asterisk.org/c/asterisk/+/15614 > [5] https://gerrit.asterisk.org/c/asterisk/+/15625 > [6] > https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Deprecations > > -- > 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
