...

...

...

...

"MT" == Mark Tearle <mtearle@tearle.com> writes:

MT> The patch is buggy and I should really get around to updating
MT> the Sourceforge web page about it.  It works OK if you create
MT> a new list but doesn't detect if the field is missing in an
MT> existing list and add it unfortunately.

MT> I'm CC'ing mailman-developers to ask for advice, I know it
MT> goes somewhere in the versioning code, but where?  And how do
MT> I do it such that future upgrades etc don't break?

The trick is to bump the DATA_FILE_VERSION in Mailman/Version.py and to add a little bit of code to Mailman/versions.py.

versions.py is the file that essentially updates the (logical) database schema when it changes. In the past there has been radical surgery in the schema, but these days it's mostly just adding new attributes to older lists. Look for function NewVars() in versions.py to see where you can add default settings for your new attributes.

When a MailList object is instantiated, its database -- which is kept as a marshaled dictionary on disk -- contains an attribute data_version which is compared against DATA_FILE_VERSION. If the latter is greater, then versions.py's Update() function is called.

This works fairly well in practice, but it breaks down when you have multiple patches each bumping DATA_FILE_VERSION, e.g. your patch cranks it to 23 while I make changes to the CVS to bump it to 27. It's probably not enough of a pain to fix, since it's quite likely that the whole mechanism will be overhauled for Mailman 3.0.

Cheers, -Barry