[Python-Dev] Importing bsddb 4.6.21; with or without AES encryption?

[Trent Nelson]

> Trent Nelson wrote:
> | Gah.  I just went and visited the Berkeley DB download site as
> | I was preparing my commit message so I could refer to the
> | exact .tar.gz being imported, only to notice that the latest
> | version is now 4.7.25.  Jesus, can we use this version?
>
> Err.... No.
>
> 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 ;-)

> I keep a private branch in pybsddb for BDB 4.7 support, waiting for
> Oracle publication. Since they already pushed 4.7.25 out (no pre warning
> for bindings developers, too bad!), I think I can publish pybsddb 4.7.0
> in a couple of days. That done, I will update python version.
>
> PS: pybsddb 4.7.0 will support Berkeley DB 4.0 to 4.7. So, the buildbots
> don't need to be upgraded.. unless we decide that Python 4.6/3.0 will
> have Berkeley DB 4.7.

    Seems like the amount of work you have to do has doubled now that you've
    been added as an svn committer, given that you're maintaining multiple
    branches of code, one for pybsddb, and one for an official Python branch.
    I was under the impression that pybsddb would be assimilated into trunk/
    Lib/bsddb and become the sole pybsddb incarnation.  That is, you'd ditch
    the separate SourceForge pybsddb project and just work directly in the
    Python tree.

    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; 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.

    It's probably safe to say that you're the one doing the most work with
    the code base and Berkeley DB in general, which means you'll be in a much
    better position to advise us as to which version we should be including or
    ignoring for a given Python release.  In general, if we can support the
    latest release, we will.

    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.  By the time it's ready
    to cut 2.7, who knows, trunk's bsddb may be supporting Berkeley DB 5.2
    at that stage.  I would also think that you could cut independent releases
    (in the sense that they're not linked to any Python release schedule) of
    'pybsddb' from the code living in trunk/Lib/bsddb.  That way, users of 2.6
    could still easy_install (or whatever) the latest pybsddb 4.8.0 to pick up
    the newest features.

        Trent.