On Thu, Oct 1, 2020 at 9:20 AM Joshua C. Colp wrote:
> 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
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
On Thu, Oct 1, 2020 at 11:01 AM Jared Smith
wrote:
> On Thu, Oct 1, 2020 at 9:20 AM Joshua C. Colp wrote:
>
>> 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,
I’m in favor of this approach as well.
On October 1, 2020 at 10:23:30 AM, Jared Smith (jaredsm...@jaredsmith.net)
wrote:
On Thu, Oct 1, 2020 at 10:04 AM Joshua C. Colp wrote:
Not really, and I think part of the problem is that this entire thing hasn't
really been documented, communicated,
On Thu, Oct 1, 2020 at 11:49 AM Seán C McCord wrote:
> On Thu Oct 1, 2020 at 10:34 AM EDT, Joshua C. Colp wrote:
> > On Thu, Oct 1, 2020 at 11:32 AM Seán C McCord wrote:
> > > I, too, am in favour of this formalization. My only comment is that it
> > > seems to me that default-enabled being
Any reason we can't "documentation deprecate" things in minor releases?
No runtime warnings and keep building by default but if we deprecate a
module in master right now it seems like the next minor release of all
active branches should document the status of the module. The fact that
a
On Thu, Oct 1, 2020 at 10:04 AM Joshua C. Colp wrote:
> Not really, and I think part of the problem is that this entire thing
> hasn't really been documented, communicated, or been a strict part of the
> release or development process. It's been more organic. Going forward it
> would be
On Thu Oct 1, 2020 at 10:22 AM EDT, Jared Smith wrote:
> On Thu, Oct 1, 2020 at 10:04 AM Joshua C. Colp
> OK, thanks for the clarification. Consider me in favor of the process as
> you outlined it, and also in favor of a more aggressive stance on
> deprecation of modules that obviously aren't
On Thu, Oct 1, 2020 at 1:15 PM Dan Jenkins wrote:
> Firstly, thank you Josh for trying to outline the process so that it's
> something that can be followed and while I agree mostly with the steps...
> the fact that its going to take 4 years for a module to be moved from
> "deprecated" to being
Yup, totally get your point as we've already discussed it on IRC... it just
feels like 4 years is an eternity. Most people don't move to a new version
of an LTS immediately and usually have a plan on how to upgrade - and its
not even like the LTS wouldnt include the module it just wouldnt be
On Thu, Oct 1, 2020 at 11:32 AM Seán C McCord wrote:
> On Thu Oct 1, 2020 at 10:22 AM EDT, Jared Smith wrote:
> > On Thu, Oct 1, 2020 at 10:04 AM Joshua C. Colp
> > OK, thanks for the clarification. Consider me in favor of the process as
> > you outlined it, and also in favor of a more
On Thu Oct 1, 2020 at 10:34 AM EDT, Joshua C. Colp wrote:
> On Thu, Oct 1, 2020 at 11:32 AM Seán C McCord wrote:
> > I, too, am in favour of this formalization. My only comment is that it
> > seems to me that default-enabled being turned off would seem to come before
> > deprecation. I can see
Fantastic idea Corey - that would get people knowing about things earlier
even if theyre not on a standard release.
On Thu, Oct 1, 2020 at 5:46 PM Corey Farrell wrote:
> Any reason we can't "documentation deprecate" things in minor releases?
> No runtime warnings and keep building by default
On Thu, Oct 1, 2020 at 1:51 PM Dan Jenkins wrote:
> Fantastic idea Corey - that would get people knowing about things earlier
> even if theyre not on a standard release.
>
> On Thu, Oct 1, 2020 at 5:46 PM Corey Farrell wrote:
>
>> Any reason we can't "documentation deprecate" things in minor
On Thu, Oct 1, 2020 at 2:18 PM Corey Farrell wrote:
> Yes I'm suggesting documenting that it is deprecated in minor releases.
> Ending support in a minor seems bad unless support already doesn't exist.
> Could we add AST_MODULE_SUPPORT_CORE_DEPRECATED and
> AST_MODULE_SUPPORT_EXTENDED_DEPRECATED
Firstly, thank you Josh for trying to outline the process so that it's
something that can be followed and while I agree mostly with the steps...
the fact that its going to take 4 years for a module to be moved from
"deprecated" to being removed just feels too long but understandable if
we're
On Thu, Oct 1, 2020 at 1:39 PM Dan Jenkins wrote:
> Yup, totally get your point as we've already discussed it on IRC... it
> just feels like 4 years is an eternity. Most people don't move to a new
> version of an LTS immediately and usually have a plan on how to upgrade -
> and its not even like
On 10/1/2020 7:56 AM, Joshua C. Colp wrote:
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
I don’t think anyone would have suggested beginning any process of removal of
the chan_sip module when development of chan_pjsip first began. In fact, the
discussion and decision of deprecation of chan_sip didn’t come about until
AstriDevCon 2018 which occurred nearly 27 months after that July
On Thu, 2020-10-01 at 20:14 +0100, Dan Jenkins wrote:
> I'd argue two years isn't exactly quick... Especially with warnings
> on previous minor releases after decisions have been made. 2 years
> is fair - 4 is just too long. But if everyone else feels like 4 is
> fine then I'll stop my protest ;)
as per my experience with systems built on top of asterisk not just vanilla
asterisk it took like 4 full years from starting implantation for pjsip
starting at Mon, 04 Jul 2016 12:
>Added PJSIP tables and started integrating itFirst round of changes to
introduce PJSIP... wow... it will be a huge
I’d personally be OK with this. The more I think about this, two years is
really long enough. With your approach below, someone would have an entire LTS
release cycle to make any necessary integration changes that come as a result
of a module that is removed. If someone complains about
Completely agree with Sean on the "what's going to be deprecated" question
months before a cut. And I like the laid out plan that would be involved
for 2 year process of deprecation,default enabled no and then remove.
On Thu, 1 Oct 2020, 22:42 BJ Weschke, wrote:
> I don’t think anyone would
Yes, or "core, deprecated in future versions" in the minors. I don't
have strong feelings on the exact language just that we should indicate
the long term future of a module has been decided.
Also sorry I accidentally didn't send my last reply to the list.
On 10/1/20 1:20 PM, Joshua C. Colp
- On Oct 1, 2020, at 7:56 AM, Joshua C. Colp 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
On Thu, Oct 1, 2020 at 2:28 PM Corey Farrell wrote:
> Yes, or "core, deprecated in future versions" in the minors. I don't have
> strong feelings on the exact language just that we should indicate the long
> term future of a module has been decided.
>
> Also sorry I accidentally didn't send my
On Thu, Oct 1, 2020 at 3:56 PM Dan Jenkins wrote:
> If there was an additional message attached to minor releases, does that
> mean we can accelerate the steps?
>
> On the question of why I'm opposed to 4 years? 4 years is an eternity to
> be in limbo - we've already seen this with chan_sip -
I'd argue two years isn't exactly quick... Especially with warnings on
previous minor releases after decisions have been made. 2 years is fair - 4
is just too long. But if everyone else feels like 4 is fine then I'll stop
my protest ;)
On Thu, 1 Oct 2020, 20:09 Joshua C. Colp, wrote:
> On Thu,
Four years, is indeed, really long. I do agree with this. As an example, I work
with another project where the work involves some integrations with software
that is in the head units of vehicles. Right now, they’re working to certify
and lock down code and functionality for the 2023 vehicle
If there was an additional message attached to minor releases, does that
mean we can accelerate the steps?
On the question of why I'm opposed to 4 years? 4 years is an eternity to be
in limbo - we've already seen this with chan_sip - even though its
deprecated in 17, people still start using
On Thu, Oct 1, 2020 at 4:31 PM BJ Weschke wrote:
> Four years, is indeed, really long. I do agree with this. As an example, I
> work with another project where the work involves some integrations with
> software that is in the head units of vehicles. Right now, they’re working
> to certify and
- On Oct 1, 2020, at 6:45 PM, Seán C McCord ule...@gmail.com wrote:
> On Thu Oct 1, 2020 at 3:07 PM EDT, Joshua C. Colp wrote:
>> I think I personally hesitate to be so aggressive because long ago the
>> project was that way. We would push to remove things faster and such,
>> and the result
On Thu, Oct 1, 2020 at 7:46 PM Joshua C. Colp wrote:
> On Thu, Oct 1, 2020 at 7:01 PM Dan Jenkins wrote:
>
>> Completely agree with Sean on the "what's going to be deprecated"
>> question months before a cut. And I like the laid out plan that would be
>> involved for 2 year process of
On Thu Oct 1, 2020 at 3:07 PM EDT, Joshua C. Colp wrote:
> I think I personally hesitate to be so aggressive because long ago the
> project was that way. We would push to remove things faster and such,
> and the result was upset people and complaints. Years later I still had
> people coming up to
On Thu, Oct 1, 2020 at 7:01 PM Dan Jenkins wrote:
> Completely agree with Sean on the "what's going to be deprecated" question
> months before a cut. And I like the laid out plan that would be involved
> for 2 year process of deprecation,default enabled no and then remove.
>
I think as soon as
35 matches
Mail list logo
