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.
