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.

On Friday, 30 November 2012 at 04:30:10 UTC, 1100110 wrote:
> Let's do this thing.

I can help with formulating a process and I can also help write up the guidelines and so forth, so I'll sign up.

If we can decide on a road map and write it up, and get enough consensus for implementing it, then everyone will know what they should be working on, and also what to expect.

How many people do you think we need to get started, 5 or so?

--rt

On Friday, 30 November 2012 at 05:17:20 UTC, Rob T wrote:
> How many people do you think we need to get started, 5 or so?

PS: We can use ALL the help we can get, I was talking about forming a core group of people who are responsible for moving things forward and getting the work organized.

--rt

On 11/29/2012 11:17 PM, Rob T wrote:
> On Friday, 30 November 2012 at 04:30:10 UTC, 1100110 wrote:
>> Let's do this thing.
>
> I can help with formulating a process and I can also help write up the
> guidelines and so forth, so I'll sign up.
>
> If we can decide on a road map and write it up, and get enough consensus
> for implementing it, then everyone will know what they should be working
> on, and also what to expect.
>
> How many people do you think we need to get started, 5 or so?
>
> --rt
>

I would hate to admit that I would consider that very optimistic...
But 5 would be more than enough to start out with.

If we get 5 now, then we will most likely achieve enough goals to truly stabilize everything from the end users perspective.

Once we start, and people start writing Code to target a release, then it's possible to do the very cool things such as automatic conversion of code to a new Version.  We just have to get to that point.

On 11/29/2012 11:17 PM, Rob T wrote:
> On Friday, 30 November 2012 at 04:30:10 UTC, 1100110 wrote:
>> Let's do this thing.
>
> I can help with formulating a process and I can also help write up the
> guidelines and so forth, so I'll sign up.
>
> If we can decide on a road map and write it up, and get enough consensus
> for implementing it, then everyone will know what they should be working
> on, and also what to expect.
>
> How many people do you think we need to get started, 5 or so?
>
> --rt
>

I've started work on the specification here https://github.com/D-Programming-Language-Stable/dmd/wiki/Specification

I'd like for someone else to start with the writeup, since I've pretty much made my ideal known by this point.

If you have a github account, give me your user name and I'll add you to the Project.

It'll at least give us a public place to define things for right now.

> Take for example Gerrit + Jenkins: Every commit is first sent to Gerrit.
> Gerrit triggers Jenkins to run all unit tests over the new commit. Jenkins
> reports the result back to Gerrit. If all tests are green and another
> developer gives his "Looks good to me" (lgtm) then the commit is applied to
> the target branch.

How would this fit into the Stable model?

Assuming 3 branches, I doubt it would be prudent to run every test multiple times.
Ideas?

On Friday, 30 November 2012 at 06:05:51 UTC, 1100110 wrote:
>> Take for example Gerrit + Jenkins: Every commit is first sent to Gerrit.
>> Gerrit triggers Jenkins to run all unit tests over the new commit. Jenkins
>> reports the result back to Gerrit. If all tests are green and another
>> developer gives his "Looks good to me" (lgtm) then the commit is applied to
>> the target branch.
>
> How would this fit into the Stable model?
>
> Assuming 3 branches, I doubt it would be prudent to run every test multiple times.
> Ideas?

I'm pretty much done for the day, so will look what you wrote up in detail tomorrow.

One quick suggestion before I call it a day, is for there to be an "experimental branch" for the great minds behind D to play around with (eg UDA's etc). We probably don't want experimental stuff going directly into a branch that is destined for stable. Unstable should be for items that are relatively finalized in terms of design and agreement that the concept is to be eventually incorporated into stable, i.e., moving a new feature into unstable starts the refinement process towards a stable release of that feature.

We could say that individual forks are good for experimental work, so there's no need for an official experimental branch, however, that will leave out the unconnected people who may want to tinker with the latest and greatest ideas that are being worked on.

I don't know really, this is just something I'm tossing out for consideration. Debian has an experimental branch, and I have a lot of respect for what that organization has achieved, so it's probably there for a good reason.

--rt

On Friday, 30 November 2012 at 05:49:34 UTC, 1100110 wrote:
> I've started work on the specification here https://github.com/D-Programming-Language-Stable/dmd/wiki/Specification
>
> I'd like for someone else to start with the writeup, since I've pretty much made my ideal known by this point.
>
> If you have a github account, give me your user name and I'll add you to the Project.
>
> It'll at least give us a public place to define things for right now.

I'm pretty much done for the day, so will look this in detail tomorrow.

BTW, Debian has an experimental branch, any use? I don't know really, this is just something I'm tossing out for consideration before I sign out.

--rt

Wait.. what happened to dlang-stable?
http://forum.dlang.org/thread/op.whi33qsp707hn8@invictus.skynet.com

On 11/30/2012 12:31 AM, Rob T wrote:
> On Friday, 30 November 2012 at 06:05:51 UTC, 1100110 wrote:
>>> Take for example Gerrit + Jenkins: Every commit is first sent to Gerrit.
>>> Gerrit triggers Jenkins to run all unit tests over the new commit.
>>> Jenkins
>>> reports the result back to Gerrit. If all tests are green and another
>>> developer gives his "Looks good to me" (lgtm) then the commit is
>>> applied to
>>> the target branch.
>>
>> How would this fit into the Stable model?
>>
>> Assuming 3 branches, I doubt it would be prudent to run every test
>> multiple times.
>> Ideas?
>
> I'm pretty much done for the day, so will look what you wrote up in
> detail tomorrow.
>
> One quick suggestion before I call it a day, is for there to be an
> "experimental branch" for the great minds behind D to play around with
> (eg UDA's etc). We probably don't want experimental stuff going directly
> into a branch that is destined for stable. Unstable should be for items
> that are relatively finalized in terms of design and agreement that the
> concept is to be eventually incorporated into stable, i.e., moving a new
> feature into unstable starts the refinement process towards a stable
> release of that feature.
>
> We could say that individual forks are good for experimental work, so
> there's no need for an official experimental branch, however, that will
> leave out the unconnected people who may want to tinker with the latest
> and greatest ideas that are being worked on.
>
> I don't know really, this is just something I'm tossing out for
> consideration. Debian has an experimental branch, and I have a lot of
> respect for what that organization has achieved, so it's probably there
> for a good reason.
>
> --rt
>
>

Hmmm...  You can easily see the available branches in git, so I'm not quite sure if this would be a good idea..

This might be where the metaphor breaks down.
We should definitely look at Debian as a successful, widely-used stable system, but we shouldn't simply copy them.

I can't think of a good reason to do this right now.

Good idea though, I hadn't even considered that myself.