> Should we implement this change without the deprecation, and rely on Ethan's > new issue #328 to take care of it later?
I was suggesting moving forward with the deprecation language for this issue and revisiting it once item #328 comes to a conclusion. There are a few other deprecation items currently in the spec (I'll add a list of those in issue #328 shortly) that we'll have to review as well. So adding the deprecation language now would mean all the current deprecations are in one place. But I'm fine either way if waiting on this deprecation language seems a cleaner approach. -- 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-846091714__;Iw!!G2kpM7uM-TzIFchu!jmWZyychiBwcOIO_b7LJ-ljdnAFFpCgjUmsx8_tnMMfOJFpAJHQFMArTqA3r4rESYxVFRI7dFUc$ 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].
