I second what @erget said. In terms of implementation of "bugfix" versions like 1.6.1, 1.7.1, etc., the github way of doing this, would be to create a branch, usually, something like v1.6.x from the commit in the history that is the release 1.6, make the changes in that branch and tag the corrected version there as v1.6.1. The branch continues to exist in perpetuity and if any more bugfix releases therein are necessary they will follow in that same branch and be tagged v1.6.2, etc. One would probably not commit to maintaining more than two major versions back, i.e. we *would* release 1.7.1 and 1.8.1, but *not* 1.6.1 since 1.6 would be considered end-of-lifed.
-- 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/329*issuecomment-864061334__;Iw!!G2kpM7uM-TzIFchu!ji5Un677qrfnCg39r4kjhEa_nInpJ7vkt889iIJKP9TXkROIUf_k2UvFcQUje9MIRGoQd8QZN8E$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, 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 cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
