TLDR: My opinion is that the rules are sound for correcting errata, but we do not describe what to do in the case of deprecation. **This may not be necessary because we could consider deprecation normal care and feeding for the standard.** I do agree that we should have a list of deprecations and the CF Checker should warn of deprecated features. We could consider deciding upon and announcing versions at which we will remove deprecated features.
Musings: I too prefer simplicity, when it's possible. Would it be possible to use the deprecation mechanism differently for 2 classes of items?: 1. Errata 2. Discontinued features My reasoning here is that we would remove these items from the standard with different speeds. As @JonathanGregory [highlights](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/328*issuecomment-845988627__;Iw!!G2kpM7uM-TzIFchu!kXYuwF-2YjStEOzj-iFUZtdCH2Jc63S_-jzEC_BSmA5IJifoAffEIYbRoKYlPgkUICwXjK1vjik$ ), there is [a procedure for errata](https://urldefense.us/v3/__http://cfconventions.org/rules.html__;!!G2kpM7uM-TzIFchu!kXYuwF-2YjStEOzj-iFUZtdCH2Jc63S_-jzEC_BSmA5IJifoAffEIYbRoKYlPgkUICwXWRmWopQ$ ) (abridged by me): > > If the change... turns out to be ... flawed, ... a new version of the > > conventions will be prepared immediately, with the second digit of the > > version number incremented, and will be recommended to be used instead of > > the flawed version. The flawed version will be deprecated by a statement in > > the standard document and the conformance document. However, any data > > written with the flawed version will not be invalidated, although it may be > > problematic for users. This remains reasonable in my mind, and it would be used in the case that quick action is needed. Then there are deprecations like @ethanrd [notes](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/328*issuecomment-846140071__;Iw!!G2kpM7uM-TzIFchu!kXYuwF-2YjStEOzj-iFUZtdCH2Jc63S_-jzEC_BSmA5IJifoAffEIYbRoKYlPgkUICwX5OjddvA$ ) - I'll speak to the use of `projection_x_coordinate` and `projection_y_coordinate` in conjunction with the `geostationary` grid mapping, as I was involved in that one. That is a feature discovered to be erroneous and deprecated by us. However, we've been living with this error for many years now and nobody complained - the deprecation was due to an (over-) abundance of precision. Thus we have not yet set a date at which mention of those attributes will be completely removed from that part of the standard; it is not urgent. We could adopt the same approach if we ever have a feature that is overly complex and we no longer want to support the use of it - I'm not advocating this, but for the sake of argument let's say it's [the use of packed data described in Section 8.1](https://urldefense.us/v3/__http://cfconventions.org/cf-conventions/cf-conventions.html*packed-data__;Iw!!G2kpM7uM-TzIFchu!kXYuwF-2YjStEOzj-iFUZtdCH2Jc63S_-jzEC_BSmA5IJifoAffEIYbRoKYlPgkUICwXLDEwogE$ ). In that case, we could deprecate the feature, and even inform users with e.g. 2 releases of notice that it will at some point disappear from the standard. In this case it would not be due to an error, but we could treat it the same way. -- 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/328*issuecomment-848506261__;Iw!!G2kpM7uM-TzIFchu!kXYuwF-2YjStEOzj-iFUZtdCH2Jc63S_-jzEC_BSmA5IJifoAffEIYbRoKYlPgkUICwXU-MfPUI$ 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].
