I was a bit confused by how the term deprecation was used by @davidhassell and 
@JonathanGregory, so I searched for it in the issue, finding that I myself 
introduced it here. Allow me to clarify how I understand it.

Deprecation doesn't apply to versions of an artifact, be it a software package 
or a standards document. Rather, it applies to specific features. What it says 
is: "We think this feature should not be used **going forward**. To allow for a 
transition period, we do not remove it at this point in time, so you can still 
use it for a bit, but we'd rather you don't, and we want to remove it in a 
later version." In my mind, it does not retroactively declare past versions 
wrong, and writing a new file today that declares that it follows the CF 
conventions version 1.6 is perfectly legal, if ill-advised.

Independent of any deprecation, we might want to have a recommendation to 
always use the latest version of CF available for new developments.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/314*issuecomment-845930836__;Iw!!G2kpM7uM-TzIFchu!m7UrRfA5tlZxyg4Pi7eKkj9J6d-d6XZWEY3lv8v91caKJPGMUG9xetGAGIMAPdyhCPGU6487Cuo$
 
This list forwards relevant notifications from Github.  It is distinct from 
[email protected], although if you do nothing, a subscription to the 
UCAR list will result in a subscription to this list.
To unsubscribe from this list only, send a message to 
[email protected].

Reply via email to