----- 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
