View mode: basic / threaded / horizontal-split · Log in · Help
November 30, 2012
D Stable Proposal
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.
November 30, 2012
Re: D Stable Proposal
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
November 30, 2012
Re: D Stable Proposal
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
November 30, 2012
Re: D Stable Proposal
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.
November 30, 2012
Re: D Stable Proposal
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.
November 30, 2012
Re: D Stable Proposal
> 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?
November 30, 2012
Re: D Stable Proposal
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
November 30, 2012
Re: D Stable Proposal
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
November 30, 2012
Re: D Stable Proposal
Wait.. what happened to dlang-stable?
http://forum.dlang.org/thread/op.whi33qsp707hn8@invictus.skynet.com
November 30, 2012
Re: D Stable Proposal
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.
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home