Florent Xicluna wrote:
However i have a worry on the "Fix oldest branch, merge to newer branches".
I guess this is due to my young experience with SVN development.

Currently, I work with 3.3 branch for my company. I checked out the trunk too,
in order to collaborate to Zope development.
So I have both '/trunk' and '/branches/3.3/' on my computer. When I prepare a
fix I do it on the 3.3 branch, I make unit/functional tests. Then I do manual
tests on my sandbox, and I commit to the branch.
Later I merge to the trunk, do unit/functional tests again and commit to the
This is acceptable workload for me.

But if I need to checkout/update all previous maintenance releases,

"all" refers to one more. There are at most only two maintenance releases.

and if i need to perform merge+tests+commit three times for every single bug, this seems a big work load to fix a bug.

If you can merge and run tests once, you can merge and run tests twice. It's mostly mechanical. Heck, I can do it on my sloooow PowerBook. Most of you guys have fast Intel machines :).

And if i have not enough knowledge of old release 3.X, this is a pain to do the

That's why it's best to fix the bug on the oldest still maintained release.

IMHO, i would prefer to keep the current bugfix policy (i.e. commit to working
release+trunk) and to have for each release someone that will do merging.

Who's that someone? Are you volunteering to do it?

In order to facilitate this process, we can enforce a workflow where committer
will warn the person in charge for release 3.X, to ask him to merge rev. 700xx
to release 3.X.

That requiers we that "person in charge for release 3.X". We currently don't have that someone.

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to