D Stable Proposal

[1100110]

In the thread: Breaking D2 Language/Spec, A lot of good points were made 
regarding a Stable branch for D.

A few of the requests were:(in no specific order)
Base Update and Upgrade paths on successful projects, such as Debian's
Three branches.

1. Stable branch
- Stable branch only receives bug fixes and is updated at predetermined 
intervals.
- Updates are clones of upstream.
- Do not update too often, as that causes too much work. (6, 8, 12 months)
- Do not break code unless extremely necessary. (Not even then?)
- Document all changes, Document every release
- Make each transition as simple as possible.
- Warn stable users about soon to be broken code.
- Do not allow Stable and upstream to diverge too much. (See Walters's 
comment regarding D1.)

2. Tools
- Provide Tools to allow easier transition between releases.

3. Testing branch.
- What should go here?  Need clear lines in the sand.

There's more, but this is already way too much for one person to handle.
But with enough support, all of them are entirely possible.

So here I have a few questions, both for the D maintainers and the 
community.

1. What did I miss that is requested?
2. What should definitely be removed?

The question was raised as to why I created a project instead of a 
simple branch.

If people want to volunteer, I can set permissions to allow them access.
A project and a branch are not mutually exclusive.
Druntime and Phobos depend on specific versions on D, do they not?
So those projects would need to remain in sync as well.

A project simplifies things to an extent.
The dmd developers do not need to have any involvement at all, or it can 
be as tightly integrated as they wish.

I can also include specific versions of LDC and GDC (and any other 
compiler willing to target a release.)

I wanted room to expand.
The worse that can happen is that this is completely ignored, nobody 
uses it, and I eventually lose interest in something that has no support 
from the community or the devs. (I'm not stopping for any other 
condition. You're stuck with me.)

The best that can happen is that D Stable receives support from the D 
Developers and the community, allowing for many tools to be created 
targeting a Stable specification of the Language.


Let's define a specification for this thing, shall we?
First things first!

How long should support of the Stable branch last?
1. 6 months
2. 12 months
3. longer (specify and give reasons)

Now how do we organize this?
1.
The current git master will be considered Unstable, and will freeze to 
define the next Stable.
Are there better ideas than this?

2.
Do we want to go with Stable, Testing, Unstable or another system?
I'd like to see some pros and cons before making any decisions.
I'm leaning towards the 3 stage system.

Yes, this is ambitious.  So is D.  And D appears to be thriving.
Yes, I know that I cannot even accomplish half of this alone.
That's the point.  There was a lot of discussion, so this obviously 
interests many people.
By myself, I can maintain a specific version of DMD with non-breaking 
bugfixes.  That is about it.

Let's do this thing.