pybsddb 5.0.0 integration and 2.7beta1 schedule
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Oracle just released Berkeley DB 5.0.21, with features like SQLite façade.
I am now testing pybsddb 5.0.0, that supports BDB 5.0.x.
My original plan was to delay integration of pybsddb 5.x.x for 2.7.1 release, but Larry Hastings has a (sensible) request to migrate pybsddb from CObject to Capsule for 2.7.0. Current pybsddb 5.0.0 already contains that change.
I am reluctant to integrate the code change before beta1, because although it should be transparent I don't want to risk a red buildbot, even for 20 minutes, so close to beta1. Integrating it between beta1 and beta2 would be riskless, but it would break API compatibility (because the CObject->Capsule) change.
I don't know how many people depend of the pybsddb C api, although I think that very little.
What should I do?. When is the beta1 window closed?
PS: I would need a couple of hours for integration, but beware timezone! (Spain :).
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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBS7t/z5lgi5GaxT1NAQL1VAP+LxE4TdHnS9hJpMj3q3GZAKz5c8ho8p2U mRpyMmIC7y9OUk5uLQYrYdGpIVVZgrCi47+Oo77lxV4tDHbbHbWXxCZcX5P1QosK HyKYVGS3nYc25WGgQvmGCtmw9LTLhiF24NHQtyzQp7LvPgCJu/OLlILaBCuYs/xX LxRJV0c9OxU= =pv/P -----END PGP SIGNATURE-----
My original plan was to delay integration of pybsddb 5.x.x for 2.7.1 release
Bugfix releases are only for bug fixes, by definition. 2.7.1 shouldn't receive such a change.
I am reluctant to integrate the code change before beta1, because although it should be transparent I don't want to risk a red buildbot, even for 20 minutes, so close to beta1.
Why should it be "transparent"? Are you so confident that it won't bring any new problems? Given that we are talking about a new major version number, this sounds a bit optimistic.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/06/2010 10:12 PM, Antoine Pitrou wrote:
My original plan was to delay integration of pybsddb 5.x.x for 2.7.1 release
Bugfix releases are only for bug fixes, by definition. 2.7.1 shouldn't receive such a change.
In the past 2.6 received a small patch to be able to compile against BDB 4.8. There are other precedents.
Why should it be "transparent"? Are you so confident that it won't bring any new problems? Given that we are talking about a new major version number, this sounds a bit optimistic.
pybsddb 5.0.0 compiles against BDB 5.0.x, but it doesn' support any new feature. The diff is pretty small, and the testsuite is very extensive. I am pretty confident.
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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBS7udh5lgi5GaxT1NAQIbDgP/YYgQSmlme8NN2dI1mO37yEJRYMP4fBCw UvowTILx6WTwEPKPCwCry33ZN+71uIxu51W0411LEhwFxnEFCM4vQYlzkZL9Y/Ym HZuEJ2xtXj7sod6mz15Qgl3C2sv3ZfL5F3V0wio0fpdaRc4H8sAc/VD0Vzixhl9g NWKGfS/y0Wo= =KopF -----END PGP SIGNATURE-----
Jesus Cea wrote:
On 04/06/2010 10:12 PM, Antoine Pitrou wrote:
My original plan was to delay integration of pybsddb 5.x.x for 2.7.1 release Bugfix releases are only for bug fixes, by definition. 2.7.1 shouldn't receive such a change.
In the past 2.6 received a small patch to be able to compile against BDB 4.8. There are other precedents.
That would be different, though. Making it work with newer versions of external libraries does not change the feature set of the module itself, and may count as a bug fix because it keeps Python compilable on systems which have the newer library installed.
A new major release of a module probably has new features, which can't be added in a bug fix release.
Why should it be "transparent"? Are you so confident that it won't bring any new problems? Given that we are talking about a new major version number, this sounds a bit optimistic.
pybsddb 5.0.0 compiles against BDB 5.0.x, but it doesn' support any new feature. The diff is pretty small, and the testsuite is very extensive. I am pretty confident.
Still, I'm skeptical whether it should be added to 2.7 this late. The original release date for rc1 was last Saturday, so any new feature proposed now should be considered as being past the deadline.
Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/07/2010 12:54 AM, "Martin v. Löwis" wrote:
Still, I'm skeptical whether it should be added to 2.7 this late. The original release date for rc1 was last Saturday, so any new feature proposed now should be considered as being past the deadline.
I agree, and that is the reason I am asking this in the list.
I still think pybsddb 5.0.0 should be in python 2.7.0. My doubt is about integrating before beta1 or between beta1 and beta2. This is important because pybsddb 5.0.0 breaks API binary compatibility for those poor souls that uses the C API exported by it. Probably only relevant to Oracle Berkeley DB XML team :-), the only people I know that uses it.
If pybsddb 5.0.0 is not integrated, there is still the issue of CObject->Capsule change.
I just read the message from Benjamin Paterson about the trunk freezing. That delays the decision until after beta1 :).
Benjamin, as the release manager, what do you think?. The options are:
Ships 2.7.0 with current pybsddb code. The CObject deprecation is currently silenced explictly.
Ships 2.7.0 with current pybssdb code + Capsule support. Current proposed patch is faulty, but solving it should be trivial. With Beta1 window closed, this will break C API compatibility in beta2... unless CObject routines can read Capsules, something that the original patch author says they do. I have not checked it.
Ships 2.7.0 with pybsddb 5.0.0. It is a low risk option, I promise. The only issue is that C API could change between beta1 and beta2. Not that anybody would use that C API, actually.
I vote for the third option. The capsule patch author Larry Hastings would like 2. The easy path ("do nothing") is 1.
PS: If we go for 1 or 2, if in 2.7.1 we want to support Berkeley DB 5.0.x (already released a week ago), we must break API anyway, because some constants have been renamed, and some defaults have been inverted.
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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBS7vhK5lgi5GaxT1NAQJmVwQAlJ/uV8uY+lUe1wEVzAOofotry91/7CML Ckf6Qvcss3JMDFDSZpVsNPiKPtodz5g0k5ws1nG6sdLEJpNz4PZXRYWI1E0lrlF9 a9D2gWalmpVRfimowxEM7aUy03rB2FGYvAYziuEkKOfYGddazZmnzU/Y9ebSphkB oJg0kxdCxDU= =xhXn -----END PGP SIGNATURE-----
- Ships 2.7.0 with current pybsddb code. The CObject deprecation is currently silenced explictly.
This is what I recommend to do. CObject should not be deprecated for 2.x, so bsddb using it is just fine - no need for change.
Regards, Martin
2010/4/6 "Martin v. Löwis" <martin@v.loewis.de>:
- Ships 2.7.0 with current pybsddb code. The CObject deprecation is currently silenced explictly.
This is what I recommend to do. CObject should not be deprecated for 2.x, so bsddb using it is just fine - no need for change.
I think this option is best, too.
-- Regards, Benjamin
On Tue, Apr 6, 2010 at 11:39 AM, Jesus Cea <jcea@jcea.es> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Oracle just released Berkeley DB 5.0.21, with features like SQLite façade.
I am now testing pybsddb 5.0.0, that supports BDB 5.0.x.
My original plan was to delay integration of pybsddb 5.x.x for 2.7.1 release, but Larry Hastings has a (sensible) request to migrate pybsddb from CObject to Capsule for 2.7.0. Current pybsddb 5.0.0 already contains that change.
After 2.7.0 is released we can't make any API change like the CObject to Capsule migration. I'd go ahead and get that in (if not for beta1, make sure it is in before beta2).
Tiny tweaks to support compiling against a new BerkeleyDB version that has the typical minor changes to their API has been done in the past on .1 or .2 releases as it makes that version of Python last longer as far as what external libraries it can link against. I wouldn't object to that, though I really don't expect there is high demand for that anymore.
I am reluctant to integrate the code change before beta1, because although it should be transparent I don't want to risk a red buildbot, even for 20 minutes, so close to beta1. Integrating it between beta1 and beta2 would be riskless, but it would break API compatibility (because the CObject->Capsule) change.
I don't know how many people depend of the pybsddb C api, although I think that very little.
agreed, probably not many.
What should I do?. When is the beta1 window closed?
PS: I would need a couple of hours for integration, but beware timezone! (Spain :).
participants (5)
-
"Martin v. Löwis" -
Antoine Pitrou -
Benjamin Peterson -
Gregory P. Smith -
Jesus Cea