----- On Oct 1, 2020, at 7:56 AM, Joshua C. Colp <jc...@sangoma.com> wrote: 

> Greetings all,
> Around this time each year a discussion always spurs (be it on IRC or at
> AstriDevCon) about deprecating modules, and removing them. I always find 
> myself
> asking "what is our real process for doing this?" in my head and end up trying
> to piece it together based on some information here and there on the wiki plus
> past experience. I'd like to better document this and put something more
> concrete into place. To that end I'd like to propose the following:

> 1. All the changes listed below initially occur in standard releases - in my
> opinion beginning the process to remove a module is a big thing and we should
> gradually introduce it, gaining feedback from those who run standard releases
> first.
> 2. The first step is marking a module as deprecated and occurs for 1 standard
> release and 1 LTS release
> 3. The second step is marking a module as defaultenabled no which means it 
> will
> not be built by default. This occurs for 1 standard release and 1 LTS release
> 4. The third step is removing the module
> 5. There will be a wiki page to keep track of all modules which are in the
> process of being removed
> 6. When a new LTS branch is created the master branch becomes eligible again 
> for
> changing the state of modules, a reminder can be done as part of cutting the
> LTS branch

> Thoughts?

The steps outlined seem very reasonable and appropriate. 

Great job on getting this hashed out and documented. 

-- 
Michael Young 

(elguero) 
-- 
_____________________________________________________________________
-- 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

Reply via email to