On Sep 10, 2006, at 9:38 AM, Philipp von Weitershausen wrote:
Tres Seaver wrote:
Stephan Richter wrote:
On Friday 08 September 2006 04:12, yuppie wrote:
The short answer is: We are a bit sloppy. I always develop
against the trunk, so when I fix an issue, I do not event think
about porting it back to another release, other when one is
imminent, like Zope 3.3 now. I think most other Zope 3 developers
are the same.
Are there good reasons why these changes were not backported?
I volunteer to backport some fixes I'm missing in Zope 3.2, but
no general solution for keeping the current stable branch
I consider this practice unacceptable for work on an allegedly
ready-for-production package. The Zope Development Process
When you check in a bug fix, you almost always need to:
* Check in the fix on the current release branch
* Note the fix in the /doc/CHANGES.txt on the current release
* Merge the fix to the trunk to be sure its fixed for the next
Only "feature work" should be done primarily on the trunk.
I agree. In Five, for example, I would first fix the bug in the
oldest maintenance release, e.g. Five 1.2, and then merge it
onwards to all newer branches (1.3, 1.4, trunk). I realize this
involves a lot of merging, but all of these branches are in
maintenance mode, so they do need to be adressed. I wrote a little
tool that made simple bugfix merges like that really easy . The
only time spent is running tests (during which I usually do my
I think the problem with Zope 3 is two-fold:
* We don't have an actual policy of what is still a maintenance
release. In Zope 2, we say that we'll maintain a release for 1
year. So that means you'll always have two stable branches (e.g.
2.8 and 2.9) and one development branch (2.10) which may or may not
be the trunk at the time, depending on whether we're before or
after feature freeze.
* Many Zope 3 developers are on the bleeding edge. And with
bleeding edge I mean trunk. Bugfixes sometimes only get
*back*ported from the trunk to the latest release branch. It should
be the other way around.
As Zope 3 is part of Zope 2 now, I think we should be maintaining
old release branches as long as their correspondent Zope 2 release
branch is maintained. That means we should change policy so that
Zope 3 releases are maintained for 1 year as well, and that
bugfixes will first go into Zope 3.2, then into 3.3 and then the
trunk. With most of the bugfixes and the right tools (e.g.
ezmerge), this isn't as much work as it sounds.
I agree in principle. In practice, I'm not sure we have enough
maintainers to get a release out, let alone maintain two previous
release branches. :( We need more volunteers.
If we want to maintain releases for a year, I suspect we need to
release once a year.
Jim Fulton mailto:[EMAIL PROTECTED] Python
CTO (540) 361-1714
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list