>> I've got a patch to do that against 2.0.8 which works for new
>> lists. If someone could tell me what the right way is to add
>> an entry into an existing database I'd have a complete patch.
>>>>> "DM" == Dan Mick <[EMAIL PROTECTED]> writes:
DM> I think Mailman/versions.py::NewVars() is the one that does
DM> all that sort of stuff. It's invoked when the version change
DM> is detected in MailList.py::CheckVersion(), though, and that
DM> version number is owned by Barry/the official distro.
DM> I think it's probably difficult to do in a patch so that it
DM> doesn't interfere with future releases.
True. Each list has an integer attribute called `data_version' and
this is compared against Mailman/Versions.py::DATA_FILE_VERSION. If
the latter is greater, then we run the schema updates in versions.py,
which currently is a morass of every change in schema or data format
since the early early 1.0 days. It's getting very close to
unmaintainable.
As Dan rightly points out though, I increment DATA_FILE_VERSION
whenever I add or change a MailList attribute, so for you to increment
it in your patch means eventually we'll conflict and some lists may
not update. But I don't think you'll need to do that.
Remember that you can always add an arbitrary attribute to a MailList
object, e.g. with bin/withlist and as long as the attribute name
doesn't collide with some existing attr name, and as long as it
doesn't start with an underscore, Mailman's persistence mechanism will
happily save and load that attribute as if it were one of its own.
So my suggestion would be to include a bin/withlist script that adds
the attribute you need and then saves the list. Don't muck around
with versions.py and Version.py.
-Barry
_______________________________________________
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
