Am Fri, 30 Nov 2012 10:19:08 -0500 schrieb Andrei Alexandrescu <[email protected]>:
> 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.
