> From: Ronald Bradford [mailto:m...@ronaldbradford.com]
> Sent: Wednesday, January 20, 2016 6:34 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Oslo] Improving deprecated options
> identification and documentation
>
>
Markus,
> > Yes, in what release it is to be removed, e.g. Mitaka. So when is
> > that release cycle, i.e. now once removed there is no record.
>
> The information at which point in time a removal will happen can be
> derived from a combination of:
> * the "Deprecation Notes" (e.g. Nova's at [1
Ronald Bradford wrote on 01/15/2016 03:04:29 AM:
> From: Ronald Bradford
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Date: 01/15/2016 03:05 AM
> Subject: Re: [openstack-dev] [Oslo] Improving deprecated options
> identification and do
On Thu, Jan 14, 2016 at 11:58 AM, Jay Pipes wrote:
> On 01/14/2016 11:45 AM, Ronald Bradford wrote:
>>
>> Presently the oslo.config Opt class has the attributes
>> deprecated_for_removal and deprecated_reason [1]
>>
>> I would like to propose that we use deprecated_reason (at a minimum) to
>> deta
Excerpts from Jay Pipes's message of 2016-01-14 11:58:13 -0500:
> On 01/14/2016 11:45 AM, Ronald Bradford wrote:
> > Presently the oslo.config Opt class has the attributes
> > deprecated_for_removal and deprecated_reason [1]
> >
> > I would like to propose that we use deprecated_reason (at a minimu
On 01/14/2016 11:45 AM, Ronald Bradford wrote:
Presently the oslo.config Opt class has the attributes
deprecated_for_removal and deprecated_reason [1]
I would like to propose that we use deprecated_reason (at a minimum) to
detail in what release an option was deprecated in, and what release it
i
Presently the oslo.config Opt class has the attributes
deprecated_for_removal and deprecated_reason [1]
I would like to propose that we use deprecated_reason (at a minimum) to
detail in what release an option was deprecated in, and what release it is
then removed in.
I see examples of deprecated_f