DMD needs branches

[Nicolai Waniek]

Hello Guys,
At the moment I'm not using D because I have no project that depends on it
(there is just a small python project in my spare time currently) but I'm
following all the discussions here about "branching" and "documentation" and
"buggy versions" and all the stuff and having professional experience with a
huge project (>1.500.000 LOC) having some problems like that and having to
integrate better bug-fixing mechanisms and so on, I would like to participate in
the discussion this time and provide some knowledge I have, though I don't know
if it suits to a 1-man-project like D is, but here are my thoughts:



I. Branching and why it is good - but more work to do

I.1 The long story

Our project was huge and there were lots of bugs in it because it based on an
old project and we couldn't dump it and begin at zero. Due to managment
problems, the software was released early and we had no "betas" - it event went
so far I was ashamed to release a version in such an unstable state. Long story
short, we Developers had to grab the steering wheel and provide more stable
versions because management just ignored what we were saying. So the first step
was to simply branch the project. We were a very small team so I know why Walter
just does not to take this step: It involves everyone in much work. The "old
branch" was just for bugfixing purposes sharing some code with the "new branch"
that got all the new features. Our customers liked it that way because though
they had to wait longer for a new feature, the version they used got stable. We
even branched it again, so that we had three branches:

1. stable, release build (called "release")
2. unstable with few new features to be tested ("beta")
3. _very_ unstable with all the new shiny things we could think of. ("unstable")

The first one, the stable branch, was that version of the software our customers
used. They got a new version about every 4 weeks.
The second version was the one with bugfixes for the "stable" on to be tested
yet and with few features that we thought were stable enough to be but from
branch "unstable" to this one.
The third branch was the one with all the new features, but heavily unstable and
- of course - untested (because developer's always exactly know what to do to
don't get exceptions, though this might not be intentionally done!).

This was lot's of work to be done, because (as mentioned above) we were a very
small team. Everyone had to do some bugfixing for the stable one. These fixes
where checked into branch "beta". When a feature of branch "unstable" was
finished and succeeded our tests, it was moved to branch "beta". "beta-versions"
were released very often because our software was used in our company, so we had
 about 20 beta-testers and hotfixes for the beta version could be done quickly
and - even better - deployed quickly to our beta-testers (it usually took less
than an hour when there was a nasty bug in the beta to be fixed). Nevertheless,
when the new features that were included into the beta were somewhat stable, we
called in a "feature freeze" and there were no changes to the beta anymore than
bugfixes for about 1-2 weeks. When this timespan passed by, the beta was
hardened enough to become the new "stable" version.

In the long run, branching was hard to do in the beginning, but it improved
heavily the stability of our software and even improved development speed
because we could concentrate on the task to be accomplished and not on "oh, when
I do this, it might break that" (because we knew a new feature won't be released
tomorrow ;) ).


I.2 How to adopt to D?

Well this might be a nice story but you might ask "what the heck does this have
 to do with D"? Your question is legitimate, but it shows how Walter could
change its development style, even when he's the only developer:

- Have a "stable" branch, that is, the one everyone should use for their real
world projects.
- Have a "beta" branch where all the bugfixes for the stable branch are
incorporated into and new features you think they are stable enough to be published
- Have an "unstable" branch were you can doodle around with everything you ever
wanted to do with the D compiler ;) When you think, feature "x" is worth it,
move it to D.
- Think of "release cycles", like "there's a bugfixed and labeled "stable" D
compiler every 3 weeks". This could be done this way: 2 weeks for new features
to be pushed into "beta", then feature freeze and afterwards one week of "beta
testing" (and I bet there are lots of D users that will participate!). During
this week, you might bugfix the nastiest bugs and then release the stable one. I
don't know how much time you have, so you might change the times from 3 weeks to
4,5,... whatever.

You don't need real branches for that, you may even just copy the source files
from one directory to another, but having a backend like SVN doing it will save
you lots of work to be done (e.g. you could share some source files through all
branches when you're certain that they won't get changed).




II. Documentation

In my opinion, documentation could be done by the community. There should be
more examples, tutorials, or whatever bundled with D when downloading so a user
does not have to navigate to 4dwiki, or whatever. This could be done by the
community itself, so no work for you: If someone has the urge to write a
tutorial/help file, just do it and the community could rate it. Simple example:
Someone writes an article about CTFE in D. The community has the possibility to
rate it from 0 (bad) - to 5 (superb). After two weeks, the article has an
overall rate of 4.3, so it's not that bad and you'll incorporate it into the
help files. Something like this... but one has to think of a number an article
has to achieve to become part of the help files (e.g. 3.75 or 4).



These are just some ideas and my opinion about "how one might do things". so
take them up and improve them, where you think something could be done better/in
another way and let us know. :)

(and with "you" I don't only address Walter, but everyone)


best regards,
Nicolai