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...
