Ken> And while a check-mh-upgrade
Ken> script might not be a bad idea, the problems I see are a) figuring
Ken> out how to let people know it exists, and b) getting people to run
Ken> it.
My thought was that it got invoked if .mh_profile didn't have the
"mh-version" line. Given your comment about this being spread out among
lots of files, perhaps we could simplify to a uniform process: all files
are versioned, and all generate the same message on being read if
there's been a relevant version change — something like this:
File <name> was created while using an old version of MH; a good way
of checking whether you really need it is to back it up, remove it,
and try this command again. If it does do stuff that you still want,
then add (or update) "; nmh-version=1.7" as the first line, and
compare it with the default version in /etc/nmh/foofile to see what's
new.
For efficiency the /etc/nmh files could be versioned too, and the
version check only triggered when their version is bumped. That way, if
release 1.7 did nothing to change /etc/nmh/mhl.reply, that would stay at
version 1.6 and the out-of-date warning wouldn't be triggered if the
user's mhl.reply was also at 1.6. Does require a partial parse of the
/etc files too, which could be annoying; perhaps the last-changed
version could be in the code instead.
Hm. Do you have a prioritised list of jobs you'd most like done?
C.
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers