<div dir="auto">We have a convention that we mostly follow. Adding new stuff with variations in the convention offers no benefit without also adjusting the rest of the API. Inconsistencies really do not assist any developer.<div dir="auto"><div dir="auto"><br></div><div dir="auto">Where APIs have been added that don't follow the conventions they should be changed. </div><div dir="auto"><br></div><div dir="auto">It really is that simple - each developer may have a different set of personal preferences and if we simply allow any two people to pick their own API pattern effectively at whim we end up with a real mess over time.</div><div dir="auto"><br></div><div dir="auto">This example is a clear cut case where we should fix the unnecessary variation in the pattern. It serves no benefit whatsoever to have such a mix of API patterns. </div><div dir="auto"><br></div><div dir="auto">We do have some variations that we should adjust - and for APIs that have been in official releases dropping in backwards compatibility macros is appropriate.</div><div dir="auto"><br></div><div dir="auto">The argument that we aren't completely consistent is specious - it is saying because we have a few mistakes that have slipped through the cracks we have open season on API patterns. </div><div dir="auto"><br></div><div dir="auto">It also would not hurt to have an automated check of API deviations on commits to catch such things in future. </div><div dir="auto"><div dir="auto"><div dir="auto"><br></div><div dir="auto">Tim.</div><div dir="auto"><br></div></div></div></div></div>