If I understand correctly, I think David is right that it's quite alright to miss fixes to trunk
and not have them applied to release branches. Better safe than sorry. Many of us (definitely me)
rely heavily on the release branch being "frozen", ie no new bugs introduced. It's easier to tell
my clients that "we've just encountered an old bug in release version, fixed it, and made release
version more stable", than to tell them that "it's a new problem, don't know if more new problems
will pop in later".
I shudder at clients' comments like "it worked before, now it's broken". Huge
confidence killer.
If the release branch gets a bug report, and a subsequent bug fix, then that bug fix can directly
be applied to the release branch. A bug fix for trunk will need extra reviews and processing to be
applied to release branch.
Personally, I think it's ok to have duplicate bug reports, one copy for trunk and one copy for
release branch, long as the duplicates were unintentional. If someone happens to spot a bug that
is *exactly* similar between trunk and release, and submits a single bug report, great. If not,
it's alright that 2 or more folks submit duplicate bug reports unintentionally, since we can still
relate the duplicates to each other.
I think the release branch is getting quite stable now. I'll know better in 3 months' time! That's
when I start my attempt to comprehensively document every above-the-framework framework
(ERP-related "framework").
But Jacques is also right that the bug reporter will know better if his/her bug fix can be applied
to both branches. Still, if the bug reporter doesn't have time to test the bug fix in the release
branch, that's still alright. The folks who discover bugs in the release branch will still search
for bug fixes in JIRA, and may try out bug fixes applied to trunk.
Maybe David didn't want to say this outright, but here's what I understand. :P Those of us who
feel that there are bug fixes to trunk that may be applicable to release, we should test those bug
fixes on release, and then report to the committers the ones that are tested to be applicable. I
may do just that systematically come December 2007.
Jonathon
David E Jones wrote:
It doesn't matter too much who does it, but it is important to
distinguish between bugs and new features (that may introduce new bugs...).
Still, as I've said before, what the release branch REALLY needs is bug
reports and testing so that it can stabilize and achieve a certain level
of confidence.
-David
On Nov 14, 2007, at 7:24 AM, Jacques Le Roux wrote:
I did it for a while. It's a delicate process has sometimes fixes are
done over changes not in release4.0. So it's better than every
commiter deals with his own commits
Jacques
De : "BJ Freeman" <[EMAIL PROTECTED]>
seems there are commits that are fixing the trunk for might be
applicable to ver 4.0
is there a review process for this?
