On Thursday, 20 December 2012 at 04:11:00 UTC, Jesse Phillips
wrote:
On Wednesday, 19 December 2012 at 23:05:59 UTC, deadalnix wrote:
master : used as a base for development. New feature are
merged here.
staging : used to provide a view of what the next version will
look like. Regular snapshot of that branch are made so public
can use the last features.
version : used to contain a version that will have a support
for an extended period of time.
I do not see how development in master is moved to staging
based on this description. I'll try and be more specific.
I realize you don't like features, but we need to talk about
Phobos additions, @property mechanics, and other highly
disruptive bugs. I'll call it the major-change.
The major-change branch is generally developed to completion
and may just be a pull requests from developer342's master.
From the sound of it this request is pulled into master. We
continue to pull many of these changes in. How do we decide
they should be placed into staging, when we pull them into
master?. If we wait for some 'magic time' how do we pull it
into staging, does that mean we now cherry pick commits of
master?
Another issue is it sounds like master becomes a "phantom"
branch. At no point in time would master resemble what is
released. I see this as a problem because it is the branch
people are developing off of, it means nothing to test in
master as staging has the actual state that will be released.
That is very true. With the given modification master and
stagging become redundant with one another. Why not get rid of
stagging ?