>Either it should be deprecated, or axed in a release without >forewarning. And if the latter then is that agreement we can do it for >other things too? After all, many users don't read the release notes >and thus miss the deprecation warnings, or they upgrade several of our >releases in one bound due to their distro, etc., striding differently, >so a feature is effectively axed for them without warning anyway.
Sigh. Ok, you caught me on this one. But ... in my defense, Content-MD5 is a giant steaming pile of poo and I would argue strongly that it's good that it's gone. First, this has been discussed being removed since 2013. People have argued that they have a use, and at first I was like, "Ok, sure, keep it if people are using it". But ... those arguments upon closer look don't (IMHO) make a lot of sense. Here are my arguments for getting rid of it, from the last time I brought it up: https://lists.gnu.org/archive/html/nmh-workers/2018-07/msg00003.html I mean ... can you muster a good argument to keep it? I haven't seen one yet that wasn't kind of vague, "Oh, I think it's good to be able to check integrity", but since we're the only ones who generate it or verify it, that doesn't seem enough justification to me. Now, some people may say, "Oh, leaving it in doesn't harm anything". Well, having been inside of nmh a lot I feel strongly that this is wrong. The INTERNALS of nmh are a mess. The Content-MD5 support was embedded at a bunch of weird layers (like in the base64 encoding and decoding routines), and I understood WHY it was there, but it makes maintenance a nightmare, because when someone looks at that code they have to understand what is going on, and that takes time where they COULD be doing something more useful. Also, in the future where I complete the Great Mime Rewrite there's no way I would implement Content-MD5 (see above for the reasons why). Okay, fine, I understand your complaint isn't really about the removal of Content-MD5; your point is that I didn't really follow the normal rules about deprecating the support and instead I just axed it. I have to plead guily there. But at my sentencing hearing I would argue that there were mitigating circumstances; namely that Content-MD5 support is essentially useless and we are better off without it. Does that justify getting rid of it without going through the normal deprecation schedule? Well, I'll let others decide that. My thinking was that for the few users that still have -check in their .mh_profiles they will hopefully see the change in the release notes and remove those flags. I didn't view it as harming anything because the only people who actually generate or check Content-MD5 headers are nmh users who have -check in their profiles and having those switches be nonfunctional won't really change nmh behavior for them. I have to believe that only a tiny number of people are actually doing that now. If you are suggesting that we just go whole hog and remove the -check and -nocheck flags that now do nothing ... well, I can live with that. As for other features ... well, if they are in the same boat as Content-MD5 then I am fine with treating them the same way (but really, that'a a special case and I can't think of anything close to that). Otherwise we should follow a normal depreciation schedule. I guess in summary: "Yes, Your Honor, I killed Content-MD5, but he had it coming and I'd do it again!". --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers