[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Planning for an upgrade path from etch to lenny for mailman

Hat: maintainer of Mailman package in Debian


It has just come to my attention that there will be no upgrade path
from the version of Mailman in etch at this time (2.1.9) to the
version lenny will most probably have (2.2.x), but there will be an
upgrade path from the yet-unreleased 2.1.y, y>9, to 2.2.x, and an
upgrade path from 2.1.9 to 2.1.y.

The reason is a fundamental file format change in how data is stored;
mailman 2.1.10 will have an "export" binary that will export the data
to a neutral (XML) format and Mailman 2.2 will have an "import" binary
that will import that format. We can do the "export" in preinst and
the "import" in postinst, but only if the package being upgraded from
contains that bin/export/.

(Shipping the said bin/export as part of the Mailman 2.2 package will
 be highly inconvenient; it is a python script that imports a
 significant part of Mailman itself; we'd have to basically ship a
 private copy of Mailman 2.1 in the Mailman 2.2 package.)

My question is: Will you accept a freeze-exception update to mailman,
or a point-release update to mailman later, to add the said bin/export
to the etch package of mailman 2.1?

Even if we include the current version of bin/export (from their SVN
repository, the 2.1.x branch) in the etch-mailman package, there is a
non-zero risk that the said XML format will change and that we will
need to update it in a point release of etch to ensure an upgrade path
to lenny.


Reply to: