Author r.david.murray
Recipients asvetlov, barry, benjamin.peterson, bradleymeck, christian.heimes, di, mylesborins, ned.deily, r.david.murray
Date 2018-12-05.22:04:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1544047493.23.0.788709270274.issue31715@psf.upfronthosting.co.za>
In-reply-to
Content
We have generally made an exception to the "new feature" rule for mimetypes.  That is, we don't really consider a mimetype addition to be a new feature in the sense that our backward compatibility rules mean.  It is true that an application could work on x.y.z and break on x.y.z-1, but this isn't because an *API* present in x.y.z is not there in x.y.z-1.  is more akin to a bugfix (it threw an exception before, now it works).  Think of the absence of the mimetype rule as a bug, rather than its presence as a feature.

And yes, this is a policy evolution.  This way of looking at mimetypes changes has been in effect for....maybe five years now?...and before that we treated them as features.  But then, too, before that we required there be an actual IANA accepted RFC, but that requirement too has had to evolve as mimetype management became more decentralized.
History
Date User Action Args
2018-12-05 22:04:53r.david.murraysetrecipients: + r.david.murray, barry, christian.heimes, benjamin.peterson, ned.deily, asvetlov, di, bradleymeck, mylesborins
2018-12-05 22:04:53r.david.murraysetmessageid: <1544047493.23.0.788709270274.issue31715@psf.upfronthosting.co.za>
2018-12-05 22:04:53r.david.murraylinkissue31715 messages
2018-12-05 22:04:53r.david.murraycreate