23 Sep
2010
23 Sep
'10
10:59 a.m.
victor Martinez wrote:
I am not agree :) As far as i see we have tried to
(more or less)
stabilize trunk before branching at least in the 2 latest releases.
This is because trunk has been in a mess for the past few releases.
Due to its instability it wasn't worth branching it as it was so far from
being releasable.
In the past we had (strived for) a 2 month release cycle.
We branched every 2 months no matter what and then worked on getting that
release out.
This is how linux and most other serious open source projects work. It's all
about discipline.
There is not an incompatibility with the
"stabilizing trunk" and
"branching" concepts. First because exists the "Hack-releases"
(fixes
just applied for the release) and that just can be done in a branch.
Second because a (more or less) stabilized trunk doesn't mean a
regression-free trunk (but it could be).
This is exactly what it's for. Branch, fix bugs or hack bugs away.
Merge real bug fixes back into trunk, tag and release.
The first main advantage (about avoid sending critical
code in the
month we are going to release) is that we will have a whole month to check
if the critical changes has waken up underlying bugs
This is the ongoing job of the testers to do both in trunk and more
importantly, in release branch.
If any serious bugs are found late in the process, drop the branch, fix in
trunk and rebranch.
The second main advantage is that we reduce the
Release Engineers amount
of work.
But you hamper development. Locking down trunk for a month before every
release is a sure way to drive away all of your developers.
I would refuse to work on a project which worked in this way, as would most
other devs I assume.
If you're finding when release time comes that no devs work on fixing the
release branch and instead continue adding new code to trunk, then you have
a developer discipline issue not a release process issue.
Locking trunk is just a way to work around your developer discipline problem
instead of tackling the real problem, your devs can't be bothered to fix
existing code and continue to ignore their duties and add new code instead.
Ged.