D Stable Proposal

Dejan Lekic dejan.lekic at gmail.com
Fri Nov 30 07:24:20 PST 2012


On Friday, 30 November 2012 at 04:30:10 UTC, 1100110 wrote:
> 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.

For all this to actually be possible we need branch maintainers - 
it is not an easy job and not many people are capable of doing it 
on production level. It is easy to complain and whine about 
problems. I haven't seen people actually offer to help here...


More information about the Digitalmars-d mailing list