From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Add Deprecated aspect to Ada 2020
Date: Wed, 30 Aug 2017 20:05:16 -0500
Organization: JSA Research & Innovation
Message-ID: <oo7ncd$69k$1@franka.jacob-sparre.dk>
References: <b8d215ba-3d49-403c-a534-27f4b8a8a00d@googlegroups.com>
 <ona3ri$10rp$1@gioia.aioe.org> <vdGmB.643570$9t6.103644@fx31.am4>
 <onfcjn$utn$1@gioia.aioe.org>
Injection-Date: Thu, 31 Aug 2017 01:05:17 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="6452"; mail-complaints-to="news@jacob-sparre.dk"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
Xref: news.eternal-september.org comp.lang.ada:47846
Date: 2017-08-30T20:05:16-05:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:onfcjn$utn$1@gioia.aioe.org...
> On 2017-08-21 21:09, Per Sandberg wrote:
>
>> Its good to use to maintain backward compatibility while notifying the 
>> users that they should change their code prior to stepping version of 
>> that particular library.
>
> I disagree.
>
> If backward compatibility can be maintained there is no reason to remove 
> the functionality. "Make it look better" does not count as one.
>
> If compatibility cannot be maintained, there is nothing to warn about, you 
> just fix the bug before next release.

Yup. This is the exact policy that we apply to Claw. One never makes an 
incompatibility that you don't have to, and that includes supporting old 
interfaces essentially forever. Perhaps the documentation and/or comments 
will suggest that new code not use the subprogram, but that's as far as we'd 
go. (There's no way to prove no one still uses a particular subprogram, 
after all, unless the entire system is in-house only.)

> You always can add new defaulted parameters, new subprograms, new packages 
> without removing old ones. Even cases like rolling up security do not 
> justify removal. You can always add backward compatible insecure mode.

Exactly. (Although the security case might be a justitification for an 
incompatibility. But in that case it would be done immediately - no waiting 
period.)

                             Randy.