Re: [asterisk-dev] Module Deprecation, Default Not Building, and Removal
- On Nov 9, 2020, at 8:23 AM, Joshua C. Colp wrote: > Since this is the first real time formalizing this once all the things are in > place (process documented on wiki, deprecation list created from existing > state > of things) I'll likely send out an email to -users and also post on the > community forums so people are aware. > Sound good to everyone? Sounds like a good approach and reasonable. -- Michael L. 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
Re: [asterisk-dev] Module Deprecation, Default Not Building, and Removal
On Mon, Nov 9, 2020 at 8:24 AM Joshua C. Colp wrote: > Since this is the first real time formalizing this once all the things are > in place (process documented on wiki, deprecation list created from > existing state of things) I'll likely send out an email to -users and also > post on the community forums so people are aware. > This sounds great to me. -Jared -- _ -- 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
Re: [asterisk-dev] Module Deprecation, Default Not Building, and Removal
Makes sense to me! Sent from my iPhone > On Nov 9, 2020, at 8:24 AM, Joshua C. Colp wrote: > > >> On Tue, Oct 13, 2020 at 7:55 AM Joshua C. Colp wrote: > >> Hey all, >> >> I just wanted to drop an email and say that this hasn't been dropped or >> anything. A 2 year option just isn't something I want to rush into without >> thinking through all the ripples, which since we're approaching AstriDevCon >> and AstriCon is something that occurs here and there at the moment. :D > > I'm back, back again. Josh is back. Tell a friend. > > After giving further thought to things and the opinions presented I think we > can safely try a 2 year approach since we have a notification mechanism in > the form of a standard release and notice in minor releases with the ability > to receive feedback from the community. This means the process would be: > > 1. Minor releases receive change to indicate that module is to be deprecated > in a future major release > 2. Module is marked deprecated and defaultenabled no in standard release > (19), which carries over to next LTS release (20) > 3. Announcement and documentation for each includes notice of deprecated > modules > 4. Standard release after this it is removed (21), which carries over to next > LTS release (22) > 5. Announcement and documentation for each includes notice of removed modules > > A wiki page would be kept to keep track of modules in process of being > removed, as well as history to show when things were actually removed. > > Since this is the first real time formalizing this once all the things are in > place (process documented on wiki, deprecation list created from existing > state of things) I'll likely send out an email to -users and also post on the > community forums so people are aware. > > Sound good to everyone? > > -- > 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
Re: [asterisk-dev] Module Deprecation, Default Not Building, and Removal
On Tue, Oct 13, 2020 at 7:55 AM Joshua C. Colp wrote: > Hey all, > > I just wanted to drop an email and say that this hasn't been dropped or > anything. A 2 year option just isn't something I want to rush into without > thinking through all the ripples, which since we're approaching AstriDevCon > and AstriCon is something that occurs here and there at the moment. :D > I'm back, back again. Josh is back. Tell a friend. After giving further thought to things and the opinions presented I think we can safely try a 2 year approach since we have a notification mechanism in the form of a standard release and notice in minor releases with the ability to receive feedback from the community. This means the process would be: 1. Minor releases receive change to indicate that module is to be deprecated in a future major release 2. Module is marked deprecated and defaultenabled no in standard release (19), which carries over to next LTS release (20) 3. Announcement and documentation for each includes notice of deprecated modules 4. Standard release after this it is removed (21), which carries over to next LTS release (22) 5. Announcement and documentation for each includes notice of removed modules A wiki page would be kept to keep track of modules in process of being removed, as well as history to show when things were actually removed. Since this is the first real time formalizing this once all the things are in place (process documented on wiki, deprecation list created from existing state of things) I'll likely send out an email to -users and also post on the community forums so people are aware. Sound good to everyone? -- 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
