Pull freeze

[deadalnix]

Le 31/07/2012 17:54, Andrei Alexandrescu a écrit :
> On 7/31/12 11:46 AM, deadalnix wrote:
>> We actually have to « reverse » the way thing are done. You can't go to
>> the other side of a gap in 2 steps. We face a change that cannot be
>> gradually adopted.
>
> Then I need more education. I thought a good thing to do is use
> branching for releases, and that we can start doing that without much
> difficulty. No?
>
> Andrei

I have tested this workflow on a big project at work. This is working, 
and much better than what we have now, but still have some limitation.

As the dev in made in master, it is sometime broken, which is a problem 
for all developers. Additionally, it become hard to apply fixes in all 
release branches.

We have found the following more successful :
  - Developing in branches. 1 branch per functionality.
  - Dev branches are often rebased on master.
  - When a feature is ready, it is integrated into master.

  - Each version have its branch (ie 2.61 is a version).
  - A version branch is often rebased on the previous version branch (ie 
2.60).
  - master is often rebased on the latest version branch.
  - A version branch is tagged to create a new release, a revision is 
added to the tag name (ie 2.61.4).

  - When a bug exists in a version branch, it is fixed in the oldest 
version where the problem appears (and that is still supported). Bugfix 
include a testcase if appropriate.

  - When several new feature want to be tested together, they are all 
merged into a branch. This is handy for testing purpose. This is usually 
done before including features in master to make sure everything is fine.

It have advantages :
  - The master is almost always in good shape. It helps all developers 
because they work on a reliable base.
  - Bug fixes bubble up from the old version to the newer one and to dev 
branches. It is easy to automate such bubbling to master with scripting.
  - It is easy to produce custom versions for testing purpose.
  - It is easy to keep several version of the product maintained, which 
a massive plus when backward compatibility is important.

Still, I'm all for what you propose, this is an improvement over what we 
have now. But the shift from « we dev in master » and « we merge dev in 
master, which is a realiable branch » can't be done in 2 steps.