12/13/2012 12:13 AM, 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.
So far me likes.
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
Just make sure your local dev is always in sync with upstream!
Or rather add an 'upstream' remote as
github.com/D-Programming-Language/phobos.git (dmd, druntime etc.) and
always do:
git pull --rebase upstream dev
git push --force origin featureName
before submitting pull via github.
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.
I find it to be 'git reset' to some early point, stash changes, fast
forward from the upstream version to the head of current branch and
stash pop your local changes.
But it really depends on symptoms and what the end result should be
discard changes?, save changes elsewhere but restore to something
stable? which branch is messed up? It's an infinite list of questions.
Is that good ?
I think it's good.
But personally I'd expect:
* master to be what you define as dev, because e.g. GitHub puts master
as default target branch when making pull requests. Yeah, I know it's
their quirk that it's easy to miss. Still leaving less burden to check
the branch label for both reviewers and pull authors is a net gain.
* And what you describe as master (it's a snapshot or a pre-release to
me) to be named e.g. staging.
And we can as well drop the dead branch 'dev' then.
--
Dmitry Olshansky
