Next focus: PROCESS

[deadalnix]

Let me do some proposal. If people are happy with them, I can 
start some wikification.

First here are the branch already existing :

dev : development branch. It is used to merge new features.
master : is the branch where the next version is stabilized 
(right now, 2.061). It receive only bug fix. eventually new 
features if the feature is of strategic importance.
2.60 : contains the current released version of D + bug fix.

Release process :

When branch 2.60 have enoug bug fixes to justify a new release, a 
tag is created (2.60.N+1). The amount and the importance of 
corrected bugs will dictate when the release is done?

When master is stabilized enough, a new version of D can be 
released. A new branch s created from master, named 2.61 and a 
tag 2.61.0 is created :

git checkout master
git branch 2.61
git checkout 2.61
git tag 2.61.0

Then, the dev version is merged into master and a new 
stabilization process begin :
git checkout master
git merge dev

At some point, 2.60 will not receive any more bug fix, and will 
be considered very stable, or dead, depending on one's standard 
(both are kind of the same).

I advice against maintaining a log of 2.XXX branches, as too much 
choice is as bad as no choice for the user, and it is no better 
for us. 2 is IMO the right amount.

NB: I have chosen the 3 number system for branches names, this is 
up to debate, but as it is widely used in programming languages 
it is a good base. Anyway, let's not debate the name for too 
long, as it really don't matter, and concentrate on the workflow.

On Wednesday, 12 December 2012 at 16:14:44 UTC, Andrei 
Alexandrescu wrote:
> Beyond that we need to have a wiki page with workflows:
>
> "To initiate a new feature"
>

A new feature is developed in its own branch. The reference is 
the dev branch. In git it goes as follow :

git checkout dev
git branch featureName

Development of the feature.

You can work on many feature at the same time; each one in its 
own branch. You initiate them the same way and switch from one 
another with git checkout.

Before submitting a feature, it has to be reabsed as follow :

git checkout featureName
git rebase dev

When the feature is ready to inclusion into dev, the dev can make 
a pull request.

> "To initiate a bug fix"
>

The same as for new feature, except that you start from the 
branch the bug is in. If the bug is in several branches, then the 
most stable one is choosen, as i is usually easier to bubble up 
the bugfix from a stable branch to dev than the other way around.

> "To initiate a library addition without formal review"
>
> "To initiate a library addition with formal review"
>
> ...
>

I don't really know what to do here. I guess bug fixes on the 
library can be done the same way, but something specific probably 
have to be done with new modules.

> All of these should be subsections in the documentation.
>
> "If your branch has conflicts"
>

If your branch has conflict, it is up to you to resolve them. The 
conflict will most likely occurs when rebasing. In such case, git 
status will inform you on which files are impacted. Edit the file 
to resolve the conflict and do git add file, then git rebase 
--continue .

If you don't want to resolve the conflict now, you can abort the 
rebase by doing git rebase --abort

> "If your branch became really messed up"
>

Well this one is difficult, because it is unclear what is wrong, 
so unclear ho to solve it.

Is that good ?