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 ?
