Is it time for D 3.0?

[Jesse Phillips]

On Mon, 13 Oct 2008 15:35:45 -0400, Paul D. Anderson wrote:

> I posted this comment already in the phobos/tango thread but I thought
> it might be of more general interest.
> 
> With all the changes being discussed -- many of the breaking changes --
> is it time to move on to D version 3.0?
> 
> It seems to me a natural division exists between 2.0, when we had to
> choose between tango and phobos; and 3.0, when we got to use them both.
> 
> Some of the other recent discussions here, template syntax, for example,
> could fall on the other side of the 2.0/3.0 divide.
> 
> I'm sure Walter and others have discussed when and how the move to 3.0
> will occur. Just wondering if this important change should be a factor.
> 
> Paul

Personally I see this a horrible reason to make a divide. Others have 
mentioned a 1/2/3 divide issue, but frankly I don't see that as 
avoidable. Look at how many options you have for a GCC versions in a 
Linux repository. I think DMD should handle many versions of itself a 
little better (conf file) but that is a different issue.

The problem is, who will want to use 2.0? Currently a big problem is the 
"wild west" syndrome that it has. If this is released having 3.0 the 
Phobos/Tango merger, people will skip 2.0 to go for Tango. Don't get me 
wrong, we have many Phobos users; we really want to get rid of this 
divide as soon as possible, not make it permanent.

On to the question of "time for a D3." Consider what happened with this 
first split.

A stable branch (1.0) was to be created that would not allow "breaking 
changes" (new features are a special breaking change as it might not 
break past code). 2.0 became the test bed for new very different ideas 
that really change how the language worked.

There had been many bug reports filed before the idea of a split came 
about. Many people did not think a version break would stop feature crepe 
of the already posted requests. This would be important in deciding what 
to split.

Another thing to look at is reducing user choice. When someone is 
creating a new project, you want them to choose the latest release for 
it. You aren't likely to choose Java 1.4 over 1.6 however, I think in D's 
case even after a 2.0 release, we will likely see such a discussion being 
made. This will be the case if the user does not like the way const is 
done, and if the Tango merge is done in 3.0 that would be another reason. 
This should be avoided, but not a reason to leave out features in future 
versions.

If a 3.0 is to be considered a clear line should be drawn and the line 
should not be a radical change for the foreseeable future i.e. when the 
split is created.