Lionel Elie Mamane wrote:
> 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?
Please keep in mind that the upgrade path from etch to lenny needs
to work for etch r0 to lenny r0 as well.
> 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.
Then the best would be to provide mailman2.1 in lenny and allow an
upgrade from mailman2.1 to mailman2.2 *in* lenny.
Regards,
Joey
--
There are lies, statistics and benchmarks.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
