On Wed, Jun 12, 2013 at 10:45 PM, David Medinets <david.medin...@gmail.com> wrote: > It troubles me that we are referring to the master branch as unstable. > While we are not following the dictums of Agile methodology it is clear to > me that the master branch should always be potentially releasable. It is > not a dumping ground for untested features or half-complete code.
I think the master should be generally stable, in the "nightly build" sense. I thought that's why we discussed feature branches. I think perhaps we're confusing "latest" and "subject to change prior to release" with "unstable". This may be a question of semantics. What do we mean if we say "unstable"? If we're defining it as "latest", "not release-quality tested", or "subject to change before a release", I think it's fine to call it "unstable". If we mean "partially completed features that are not remotely ready to be tested for a release", I think we definitely don't want that kind of "unstable" in master. [snip] > The SHA1 value of a change tracks it across all branches. No need to > perform no-op merges. Simply check the branch history to see it contains > the SHA1 hash you're interested in. [snip] I think it's still useful to merge forward (even if it's an effective "no-op"), for two reasons: 1) It keeps the history between older supported versions and newer versions linear, which makes it easier to merge non-"no-op" fixes across supported versions. 2) It's still useful to record that a bug has been at least considered and resolved in a newer branch, even if nothing needs to be done. Simply requiring that the merge process be performed as a part of the workflow helps prevent bug regression. -- Christopher L Tubbs II http://gravatar.com/ctubbsii
