Deprecated Library Functions / Methods

Johannes Pfau nospam at example.com
Fri Nov 30 11:11:28 PST 2012


Am Fri, 30 Nov 2012 10:19:08 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> On 11/30/12 10:04 AM, Chris wrote:
> > Is there a way of telling when things in the library will calm down
> > and it'll be save to develop in D and update old code?
> 
> Thanks for this testimony.
> 
> Andrei

I think what we need is a "hard cut" for phobos.
We could release 2.061 and then stop all regular bug fixing /
enhancement work on phobos for two weeks. In those two weeks all work
would be concentrated on reviewing the existing phobos modules. So we'd
start a wiki page, assign every module to at least one person reviewing
it. Those people should correct naming and codig style of the module in
their local repositories. Controversial changes could be discussed on
the wiki. If names have to be changed to match the coding conventions
the old names should be deprecated.

Some modules should be deprecated as a whole, even if we do not yet
have a proper replacement yet. For example we know for many years that
std.xml is broken and nobody is fixing it, but we still ship it with
phobos. std.signal is written in an old D1 style. std.json should
probably be removed as well. We should get rid of all that legacy even
if we don't have a replacement yet.

In the end we would have a 2.062 release with all the old functionality
(deprecated) and new functionality / names matching our coding
conventions. Some releases later (e.g. 2.064) all deprecated
functionality will be removed. Then everyone knows that:

* The new functions in 2.062 should be used ASAP. 
* 2.063 will be the last version supporting the deprecated
  functionality.
* 2.064 will be 'clean'. All deprecated features will be removed and
  the rest of the functions will be stable. (At very least there will
  be no more naming changes or similar stuff)

So we'd end up with a phobos with less functionality because of the
dropped features and upgrading user code to 2.064 might be a bigger
task, but we will guarantee that there will be no (or at least very few)
breaking changes after 2.064 and obeying the naming conventions in all
modules should lead to a better user experience.


If someone really needs a deprecated module like std.xml it could
always be maintained in a different repository / project but we should
remove everything from phobos which doesn't fit our quality standards.


More information about the Digitalmars-d mailing list