D versionning

Jonathan M Davis jmdavisProg at gmx.com
Sun Jul 15 16:34:05 PDT 2012


On Sunday, July 15, 2012 16:07:40 Walter Bright wrote:
> On 7/15/2012 3:43 PM, Jonathan M Davis wrote:
> > On Sunday, July 15, 2012 15:30:57 Walter Bright wrote:
> >> On 7/15/2012 3:27 PM, Jonathan M Davis wrote:
> >>> The problem is that we're still ironing out too much, and most of the
> >>> breakage relates to bug fixes, not new features.
> >> 
> >> There's been a lot of non-bug-fixing breakage, for example, renaming
> >> library functions.
> > 
> > Yeah, but those are always done through a deprecation path, so there's no
> > immediate breakage. And we've done most of that already, so that should be
> > happening less and less.
> 
> It needs to stop completely.

Most of the renaming of functions which has gone on has been because Phobos 
has been inconsistent with its naming, which makes it harder to use and learn. 
As that's sorted out (as has mostly been done), those changes will stop. But 
do you honestly expect that everything in the standard library is going to be 
frozen at some point? Is that what you're suggesting?

If we figure out that function X really should be replaced, we should be able 
to replace it. If we come up with a way better design for a module, we should 
be able to replace it. That may mean leaving the old version around for a long 
period of time, but we shouldn't be stuck for bad design decisions 
permanently. That's actually one area where having major and minor releases 
(in addition to D1 vs D2 vs D3 etc) can really help, because then you restrict 
the larger changes to the major releases. Major libraries do this all the time 
(e.g. Qt).

We definitely want to be more stable than we have been, and we want to reach 
the point where there are no longer any minor changes for naming and whatnot 
(and we're getting there), but if you want to freeze the API on Phobos 
permanently, making it so that we can only ever have additive changes, then 
there are going to be a number of people who are going to be very unhappy. In 
the long run, breaking changes should be better managed (e.g. restricted to 
only certain releases) and much rarer, but they still need to be able to 
happen.

- Jonathan M Davis


More information about the Digitalmars-d mailing list