-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trent Nelson wrote: |> It is not clear to me that python 2.6/3.0 will be published with BDB 4.6 |> or 4.7 support. 4.6 has several known issues, apparently solved in 4.7. | | I could have sworn I heard a few people mention that "4.5 has issues, | but they're solved in 4.6" at PyCon ;-) Or course, it is natural to expect new releases to solve known issues. But initial releases of BDB 4.6 were crappy (current ones are fairly good, even if they didn't patch the "compact()" crash :). I glad to say than pybsddb3 testsuite has catched a few errors in Oracle BDB 4.7 pre-releases, so I'm fairly confident in the final version. | I think I remember reading some concerns you had about doing this last | week though, surrounding things like wanting to be able to release pybsddb | versions more frequently than Python versions are released. Just because | you live in trunk/Lib/bsddb shouldn't prevent you from doing this though; | in fact, as long as you're sensitive to major release timeframes, I'm | sure we'd love trunk to always track the latest Berkeley DB version; This issue is complex and I would like to delay a hard decision until it becomes a real issue. Currently, I rather prefer to keep them apart (but in sync). Aside the frequent release issue (something that would not be an issue when pybsddb3 cover the entire Berkeley DB API, some day), there are mailing lists, community support, open patch submission, etc. I know that merging can be a bit painful. Been there, done that. I'm waiting SVN 1.5 release and its much improved merge repeated merge, like the holy grial :-p. Someday Mercurial could be integrated in Python version control system, and I would sleep better at night. Meanwhile, bsddb patches in the python side are few and apart, and I can cope with them. I want to shield python-dev of this: """ [jcea@tesalia trunk]$ svn diff svn://svn.argo.es/jcea/pybsddb/tags/4.7.0 svn://svn.argo.es/jcea/pybsddb/trunk | wc ~ 1275 3554 37696 """ About ten big commits. And 4.7.0 was released mere hours ago... | if | all the buildbots stay green with 4.7 and there are no regressions in | functionality, then hey, lets go with 4.7 for 2.6/3.0. I will write about this, after you upgrade MS Windows buildbots to 4.7.25. Let's see how it behave. I rather prefer BDB 4.7.25 in Py2.6/3.0 than BDB 4.6.21, unless we discover some ugly bug in last release (as was discovered after 4.6 release; gracefully no python version was released using the faulty lib). I'm using this 4.7.0/4.7.25 release for... uhmm... 20 hours now. No issues so far, in a very BDB busy machine (mailserver, storing user mailboxes via Python->Durus->my durus backend for Berkeley DB->pybsddb3->BDB 4.7.25). A couple of millions emails per day :). | If Oracle come out with Berkeley DB 4.8 a week after 2.6 is released, | that's fine, we'll keep release26-maint chugging along with 4.7, but we | can switch trunk over to 4.8 once you're ready. One of the "problems" with Berkeley DB is that upgrading libraries can require "upgrade" also the database files. The "upgrade" is usually painless, but you can't go back. So, any BDB upgrade in a python release must be clearly marked, because it can become a no-return-point for some users. In Unix world, Python releases would use BDB installed in the system. So, the user/admin has control over BDB upgrades. But since MS Windows Python bundles BDB, we need to be extra-careful there. Someday we need to talk about pybsddb3 "eggs" (via pypi) supporting BDB DLL bundled by stock python in MS Windows. Current approach needs a new DLL. Some *other* day. So much to do, so little time... :). - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDW1rplgi5GaxT1NAQJEpQP+IFcmL+0zqg1n8MrtyvPiRZk4oBSlwUzD Ov0SHVmx8MmhKk5NOI3FjpKSVZIVU55HZ+qFBuqz12VeYOucZOUeDlsE5LFnmXsC E4HR6+NCi7zHSOyESjy6j6M3rNPWqNiPOUnJ5kevDOcnoA+W8urdj97wHflArsJ3 e1M1R04UoMI= =lisl -----END PGP SIGNATURE-----