Dear Klaus et al. @zklaus commented as follows in https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/314__;!!G2kpM7uM-TzIFchu!nHDyAHj9kmDbf6NXvb4CglGp1Vw7hYsmYYYbIWc5lyf905JeuRioNjUFXRz1nR3fHYFBanWeMMI$ :
> 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. Maybe we didn't use the word "deprecation" correctly in the [rules](https://urldefense.us/v3/__http://cfconventions.org/rules.html__;!!G2kpM7uM-TzIFchu!nHDyAHj9kmDbf6NXvb4CglGp1Vw7hYsmYYYbIWc5lyf905JeuRioNjUFXRz1nR3fHYFBBPYbqXE$ ), where we wrote: > If the change, once implemented in the conventions, subsequently turns out to > be materially flawed, meaning that data written following the convention > could be somehow erroneous or ambiguous, a github issue should urgently be > opened to discuss whether to revoke the change. If this is agreed by a > majority of the committee, 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. As Ethan has said, in this case there is no change to be revoked - we hadn't anticipated that we would discover an error that affects all existing versions! Nonetheless, the principle ought to apply. Data written with the flawed versions (all existing ones) is still legal, but might be problematic, so we want to minimise the use of these versions for new data. In my opinion, we _are_ saying retroactively that all these versions are _wrong_ - not everything which is legal is right, after all! To deprecate something means to express disapproval of it. That is what we are doing. We disapprove of all these versions, but only as regards the specific feature we are correcting. Hence my proposal that we deprecate the versions <1.9 in this feature only. Best wishes Jonathan -- 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-845988627__;Iw!!G2kpM7uM-TzIFchu!nHDyAHj9kmDbf6NXvb4CglGp1Vw7hYsmYYYbIWc5lyf905JeuRioNjUFXRz1nR3fHYFBDDJHBW4$ 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].
