On Friday, 21 December 2012 at 18:34:12 UTC, Rob T wrote:
On Thursday, 20 December 2012 at 23:43:12 UTC, Joseph Cassman
wrote:
Just some food for thought.
In the section about the "Branching model", the wiki currently
has a staging branch in addition to the master branch. From
what I understand, the idea seems to be to vet a release on
staging until it is considered production level and then
marked as the release.
Another idea could be to keep the quality of the master branch
at a high level so as to be able to branch into a release at
any time, directly from master. Before feature branches are
merged back into master, their quality is vetted so the
quality of master is maintained.
This idea seems similar to what is used for the vibe.d project
(http://vibed.org/temp/branch-model-small.png). My apologies
if I misunderstood their process.
It looks like Xamarin has been using this process for a while
and it seems to be working for them.
http://tirania.org/blog/archive/2011/Oct-14.html
Joseph
Doesn't that just turn master into staging, and turn the
feature branches into a diluted and distributed version of
master?
If there's no common development branch to work with that
integrates the most current features together, then how will
such a thing ever be properly tested before going into a high
quality common branch?
We also need the ability to stop brand new poorly tested
features from making their way into a release, so at some point
a common pre-release branch needs to be frozen from receiving
any new features so that it can be honed into a high quality
product. If you use the master branch for such a thing, then no
new features can go into it, so with master frozen, what common
branch is available for the devs to merge their new work into?
--rt
Precisely.
I think people just don't understand the purpose of these
additional branches. The point being - integration.
The general flow of events should be:
1. Developer has cool idea/feature which he explores on a
separate private "feature branch"
2. During development of the feature the developer can optionally
collaborate with other developers. This can be done either by
pulling from other developers' repositories directly or by
pushing to a branch on github. Either way, this is an ad hoc "my
new feature" branch.
3. First level of integration - feature is complete and is merged
into official first level of integration - the "dev" branch
(consensus was to use master for that)
4. Feature can than be further refined and _integration bugs_ can
be fixed by the general dev team.
5. When the "dev" branch is considered stable enough by the team
(exact criteria to be defined later), the changes are merged to
the _2nd level of integration_ - the "staging" branch. This
allows for a wider audience to test and provide real-world
feedback.
6. when the 2nd level of integration is complete, the changes are
stable enough to be released and the included features finalized.
Since git provides each developer with their own private copy of
the entire repository there is *no need* to define any official
processes prior to initial integration. The developers are free
to collaborate by using ad hoc branches. The only common sense
recommendation I'd give (again, NOT part of the _official
process_) is to use meaningful branch names if they are meant to
be shared with other people.