Re: [Zope3-dev] Re: SVN: Zope/trunk/lib/python/ use a specific revision of the Zope 3 trunk for now until we have some sort of tag
On Friday 11 November 2005 12:15, Tres Seaver wrote: Philipp von Weitershausen wrote: Log message for revision 40048: use a specific revision of the Zope 3 trunk for now until we have some sort of tag available (e.g. a Zope 3.2 beta tag). We should have cut a Zope3-3.2 beta tag on the day of the feature freeze, so that release / stabilization activities could proceed without leaving the trunk frozen. In fact, I thought we had committed to do first beta for 2.9 and 3.2 on 1 November. Even if we don't branch at those points, we should be tagging the freeze point any any intermediate OK, fixed that, now try again points. Yeah, but the bug day was a big flop for both Zope 2 and Zope 3, so Andreas and I (and even with Jim's approval) decided not to release. I also will not cut a branch until more bugs have been fixed, so that I lower the bar for bug fixers and force people to work on bugs not features. BTW, I think that Philipp did the right thing. Depending on a specific revision is fine, though pointing to the trunk right now would work too, since it is feature frozen. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: SVN: Zope/trunk/lib/python/ use a specific revision of the Zope 3 trunk for now until we have some sort of tag
Stephan Richter wrote: On Friday 11 November 2005 12:15, Tres Seaver wrote: Philipp von Weitershausen wrote: Log message for revision 40048: use a specific revision of the Zope 3 trunk for now until we have some sort of tag available (e.g. a Zope 3.2 beta tag). We should have cut a Zope3-3.2 beta tag on the day of the feature freeze, so that release / stabilization activities could proceed without leaving the trunk frozen. In fact, I thought we had committed to do first beta for 2.9 and 3.2 on 1 November. Actually, I said we ought to be ready for the first beta by Nov 1. :) Even if we don't branch at those points, we should be tagging the freeze point any any intermediate OK, fixed that, now try again points. Absolutely. Yeah, but the bug day was a big flop for both Zope 2 and Zope 3, so Andreas and I (and even with Jim's approval) decided not to release. I also will not cut a branch until more bugs have been fixed, so that I lower the bar for bug fixers and force people to work on bugs not features. BTW, I think that Philipp did the right thing. Depending on a specific revision is fine, though pointing to the trunk right now would work too, since it is feature frozen. No, it wouldn't. In my strongly held opinion, you should never depend on a trunk or branch unless the people checking in there are running *your* tests before a checkin. A bug fix I made earlier this week actually broke a Five test. Depending on revisions, which you update frequently, provides important stability. The person who updates the revision can first make sure all their tests pass, addressing any issues before checking in. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: Zope/trunk/lib/python/ use a specific revision of the Zope 3 trunk for now until we have some sort of tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Friday 11 November 2005 12:15, Tres Seaver wrote: Philipp von Weitershausen wrote: Log message for revision 40048: use a specific revision of the Zope 3 trunk for now until we have some sort of tag available (e.g. a Zope 3.2 beta tag). We should have cut a Zope3-3.2 beta tag on the day of the feature freeze, so that release / stabilization activities could proceed without leaving the trunk frozen. In fact, I thought we had committed to do first beta for 2.9 and 3.2 on 1 November. Even if we don't branch at those points, we should be tagging the freeze point any any intermediate OK, fixed that, now try again points. Yeah, but the bug day was a big flop for both Zope 2 and Zope 3, so Andreas and I (and even with Jim's approval) decided not to release. I also will not cut a branch until more bugs have been fixed, so that I lower the bar for bug fixers and force people to work on bugs not features. I don't understand avoiding making a beta because of known bugs -- beta is not the same as release candidate, and doesn't imply that there are no known issues. I believe that leaving the trunk frozen for a substantial length of time has a chilling effect on the health of the project, which *contributes* to the length of the beta period, rather than shortening it. The poster child for my argument is the 3.1 release cycle, which lasted for 9 months! BTW, I think that Philipp did the right thing. Depending on a specific revision is fine, though pointing to the trunk right now would work too, since it is feature frozen. Depending on numeric revision IDs obscures intent: if we aren't going to make a release branch, and tags from it, then we need at least to be creating alpha-ish tags from the trunk, and having dependents use those tags. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDdjxJ+gerLs4ltQ4RAhRqAJ4+5OobRv4YLKrLtMSgwnRnAklxlACglTaC E8AxPKU+/xyxUl7m/MZe0A0= =QQxl -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
