[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Correct branch for bug fixes
From: |
John W. Eaton |
Subject: |
Correct branch for bug fixes |
Date: |
Mon, 3 Oct 2011 16:36:45 -0400 |
On 2-Oct-2011, Rik wrote:
| Should we be holding off on any commits to stable? The 3.4.3-RC0 candidate
| seems to mostly work so I have been reluctant to commit anything to the
| stable branch even when it is a bug fix or just a documentation change.
| Instead, I've been committing bug fixes to the dev branch since that will
| be the next release.
|
| I potentially do have two useful candidate patches for 3.4.3-RC1 if we make
| such a tarball. They both fix 'make test' errors on the MinGW platform.
I think changes to docs or tests could be applied with little risk.
If there are bug fixes, then I think it depends on the details of the
fix and bug.
If we could reduce the time between major releases to 6-9 months, then
I think we should be more selective about what goes on the stable
branch. Currently we put a lot of bug fixes there, even some that are
not very well tested or otherwise risky. Instead, I think we should
only be fixing problems that are known to be regressions from previous
behavior. Then we have a better chance that each point release is
more stable than the last, even if some reported bugs are not fixed.
Meanwhile, if six months is too long to wait for a new stable release
that includes the bug fix, then we publish patches as soon as we make
them. And there is always the option of paying for support...
jwe