What does the twice-annual release policy say about bugs and/or packaging errors that are identified and fixed within a very short time of the official release announcement? Log message for revision 41228: Merge r41227 from 2.9 branch: Update Five to bugfix release 1.3.1. Changed: U Zope/trunk/lib/python/Products/Five/CHANGES.txt U Zope/trunk/lib/python/Products/Five/site/localsite.py U Zope/trunk/lib/python/Products/Five/site/tests/sitemanager.txt U Zope/trunk/lib/python/Products/Five/tests/adapters.py U Zope/trunk/lib/python/Products/Five/version.txt (...) +* Fix an adapter look-up bug in the local site implementation +that was due to an oversight during the port to Zope 3.2. I'm building from svn, so it doesn't make much difference to me, but I was curious whether the circumstances (if any) that would trigger bugfix releases were documented anywhere.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Kowalczyk wrote:
What does the twice-annual release policy say about bugs and/or packaging errors that are identified and fixed within a very short time of the official release announcement?
Log message for revision 41228: Merge r41227 from 2.9 branch: Update Five to bugfix release 1.3.1. Changed: U Zope/trunk/lib/python/Products/Five/CHANGES.txt U Zope/trunk/lib/python/Products/Five/site/localsite.py U Zope/trunk/lib/python/Products/Five/site/tests/sitemanager.txt U Zope/trunk/lib/python/Products/Five/tests/adapters.py U Zope/trunk/lib/python/Products/Five/version.txt (...) +* Fix an adapter look-up bug in the local site implementation +that was due to an oversight during the port to Zope 3.2.
I'm building from svn, so it doesn't make much difference to me, but I was curious whether the circumstances (if any) that would trigger bugfix releases were documented anywhere.
I think the trigger is one of the following: - The release manager sees the prbolem, says "Oh, $#1^!", puts on the obligatory brown bag, and pushes one out ASAP (this one is typical for glaring security holes). - Some large-scale user (or upstream framework) is trying to make a release, and needs an unreleased fix. They lobby for a "third dot" release that their own deployment can then rely on. I haven't seen enough other cases to classify them. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDwaHr+gerLs4ltQ4RAjbVAJsEugXRYrz4yQZzN/0YYOk5OCQAdwCeL/hF T6VK1LTRBpc9bSKHLi/O6ik= =OqG6 -----END PGP SIGNATURE-----
--On 8. Januar 2006 17:49:01 -0500 Jeff Kowalczyk <jtk@yahoo.com> wrote:
What does the twice-annual release policy say about bugs and/or packaging errors that are identified and fixed within a very short time of the official release announcement?
huh? I don't understand. Bugfixes will be appear as in the past: - when security related fixes were made - when enough uncritical bugs were fixed - when the release manager has time and is release mood :-) -aj
Since this particular bug should be circumventable (new word?) by using Five 1.3.1, it's not serious enough to warrant a release by itself, IMO.
[Jeff Kowalczyk]
What does the twice-annual release policy say about bugs and/or packaging errors that are identified and fixed within a very short time of the official release announcement?
I think the answer you're looking for is that the policy says nothing about that. Every-6-months applies to the 'j' position in i.j.k (like moving from Zope 2.9 to Zope 2.10). Those can introduce new features. Changes only in the 'k' position are bugfix-only releases, and in theory there could another one of those every day ;-).
participants (5)
-
Andreas Jung -
Jeff Kowalczyk -
Lennart Regebro -
Tim Peters -
Tres Seaver