git workflow draft

[Matthias Fuchs]

Am Donnerstag 17 Februar 2011, 13:46:04 schrieb Johannes Sixt:
> Am 2/17/2011 12:10, schrieb Andreas Hartmetz:
> > On Thursday 17 February 2011 09:01:05 Johannes Sixt wrote:
> >> When you develop a new feature, it is a very important choice on which
> >> version of the software you base it on. I am advocating to base a
> >> feature on a well-known, stable state. If you choose to base the
> >> feature on "today's master", you are actually building a house on
> >> moving grounds. How can you be sure that your product will be stable?
> >> 
> >> The corollary is that a new topic should be based on a project state
> >> that is no younger than necessary (to have all prerequisites that you
> >> need), so that you can be sure that it was already tested by a as many
> >> people as possible. Ideally, today, every feature targeted for 4.7
> >> should be based on the 4.6.0 release tag, whenever possible.
> > 
> > As somebody who usually runs master, I see a bit of a problem here.
> > Everybody who is working on a feature will not be testing master
> > (aspects related and unrelated to the branch) while doing so. This may
> > or may not turn out to be a problem in practice.
> 
> You do have a point here. However, I believe that it should not be a
> problem in practice:
> 
> You start a topic from a stable state that is not today's master. You
> develop the topic for a few days, or a week or two. During this time, you
> do diligent testing, and at the end you are reasonably sure to have a new
> good state. The goal here is that your testing does not suffer from
> unrelated breakages introduced by other topics that are in flight.
> 
> At this point, you want to make sure the topic is good when it's merged
> into master. Do that. And repeat all tests.
> 
> Now it's time to publish the topic. You do so by pushing the topic branch
> (not the merge!). You encourage others to merge the topic into their
> *private* repositories to get wider exposure and testing.
> 
> Yourself, you keep running the merged state, of course. You would also do
> the regular merges from upstream that you used to do. See? You are still
> testing master. If you like, you would merge topic branches offered by
> others to test their topics as well.
> 
> When your topic has cooked sufficiently long, you would repeat the merge
> into today's master (remember: do not expose your own private, messy merge
> history to others), and push the result upstream. Now the topic is in
> master.
> 
> > Maybe we'll find rules of thumb to choose the right base for topic
> > branches. Like "usually latest stable unless you rely on features of
> > master" or "usually master unless changes in master would interfere with
> > your work"... A checklist with obvious and not so obvious arguments for
> > / against choosing a particular base could also help make decisions on a
> > case-by-case basis.
> 
> If the project hygenie that I sketched above were applied universally,
> today's master would actually be a reasonable choice (contrary to what I
> said earlier).
> 
> Until then, a relaxed rule is probably sufficient: Choose a starting point
> that is convenient; but DO NOT CHANGE IT once you have done serious
> development, because a change (aka rebase) basically invalidates all your
> tests.
> 
> And common sense says: If you are cleaning up your messy topic history
> using git-rebase in such a way that you have to re-test every new commit
> anyway, you CAN choose a new starting point.
> 
> -- Hannes

I don't really agree.
Often you don't really depend on master, _but_ master will be the next stable 
release.
There can be many interdependencies which would not show up if you based your 
work on the current stable branch. And as a feature would never be added to 
the stable branch anyway I see no reason to work on a branch of it for a 
feature.
What would that gain me?

If I base it on master in fact errors could turn up which have nothing to do 
with the feature. But would that be bad? Wouldn't that rather result in faster 
fixes in bugs, no matter where they are? Wouldn't that result in a better next 
stable version as errors turn up earlier?