On 4/17/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote:
Here I disagree: if a bug affects a version of the 1.3 branch, the bug must be fixed in the branch, then verified if in the trunk exists and, eventually, fix it and test it.
Historically, we have considered the trunk the active line of development. ATM, we have active branches in both Struts 1 and Struts 2. But, in both cases, I believe we still consider the trunk the one-true-codebase. In effect, 1.3.x and 2.0.x are maintenance branches. My understanding is that the branches were created as temporary expediencies while we develop brave new features for the trunk. Once the trunk is ready for release, the branches would become inactive, unless a serious (e.g. security) flaw is uncovered. When we create a maintenance branch, it would seem to be rare for a bug to affect the branch and not the trunk, since the trunk is a superset of the branch I'd say the fix should be tested against both the branch and the trunk. At least, that's what I've, and I believe others, have been doing wth 2.0 and 2.1.x ( I suppose we could wait and try and merge a branch into the trunk later, but I would be concerned that some fixes might not be compatible with the whatever brave new changes we are making to the trunk, implying the fixes should be tried one-by-one or at least in small batches, before the branch is released again. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
