Martijn Faassen wrote:
Thanks for doing this work, Christian. I'm in favor of going for Zope 3.4 on a timely basis.

I wouldn't mind that.

Concerning the delay of Zope 3.3, I think we should consider whether we're not too perfectionistic.

On the one hand core developers seem to be happy to use the trunk for development projects, and on the other hand we demand a lot of work doing bugfixes in a release, up to the point where we delay the release itself. That's a bit paradoxical - evidently the bugs aren't harmful enough to harm these developers much most of the time, but at the same time we consider them extremely harmful if they should appear in a release.

I've come to wonder the same thing.

What about a policy where we fix bugs until the release date, and then on the release date, we actually release? Any bugs that are still in it are going to go with it.

Yes, provided we have a release branch babysitter who will spit out new bugfix releases once a final release has been made. I'd be willing to do this for Zope 3.2, provided people actually do their bugfixes there.

Anyway, if the Gnome project can do time-based releases *on the date* we should be able to do it too.

I bet the Gnome project has members who are actually paid to do this kind of release management, though. That doesn't mean we should postpone a final release over and over again, just because we don't have the resources. In fact, because we don't have the resources, we should release a final anyway and catch up with bugs in, well, bugfix releases :).

Zope3-dev mailing list

Reply via email to