Hi Ken, > > 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. ... > 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.
But what about our releases not matching many users' upgrade schedules so our one-release deprecation notice is of no use to many? That would suggest more rapid change could be possible without the wait-a-release delay. The alternative is to fudge it by releasing more often so we can hoodwink them in another way that they were given fair notice. :-) -- Cheers, Ralph. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
