Update README with new findings and increment version to 0.0.10

.zenodo.json

@@ -23,7 +23,6 @@
   "license": "gpl-3.0",
   "keywords": ["test", "EMERGE"],
   "notes": "This is the 'notes'",
-  "grants": [{"id": "10.13039/100000001::2022070"}],
-  "version": "0.0.9",
+  "version": "0.0.10",
   "communities": [{"identifier": "emerge-bii"}]
 }

README.md

@@ -10,11 +10,13 @@ Metadata is stored in the .zenodo.json file, which is formatted based on documen
 
 ## Specific instructions and test results for .zenodo.json properties
 
-To update metadata for the Zenodo record, update the corresponding properties in the .zenodo.json file, and then create a Release on GitHub. Based on previous tests, nothing will be updated on Zenodo until a GitHub Release is created, but the update happens almost instantaneously once that's been done (assuming the json contains valid metadata). 
+To update metadata for the Zenodo record, update the corresponding properties in the .zenodo.json file, and then create a Release on GitHub.  Based on previous tests, nothing will be updated on Zenodo until a GitHub Release is created, but the update happens almost instantaneously once that's been done (assuming the json contains valid metadata).
 
-Note that if .zenodo.json contains *anything* not recognized by Zenodo as valid, then the Release will fail to be posted to Zenodo, and will only succeed once the errors have been corrected and put into a new Release. 
+Note that if .zenodo.json contains *anything* not recognized by Zenodo as valid, then the Release will fail to be posted to Zenodo, and will only succeed once the errors have been corrected and put into a new GitHub Release. Unfortunately, just editing the Release to point to a new tagged commit doesn't appear to have any effect on Zenodo, even if the Release has not yet been pushed there (or, if it *has* been pushed to Zenodo but with incorrect metadata, then updating the GitHub release to point to a different tag will simply create conflicting versions between GitHub and Zenodo; this practice is therefore strongly discouraged). However, once a corrected Release has been made, it should still be possible to delete the old failed one on GitHub to keep things tidy. You can also use the "pre-release" checkbox on GitHub to indicate releases that are still in the testing phase (and then uncheck this box later), as this checkbox appears to have no effect on Zenodo.
 
-See Release "version 0.0.8" for the most comprehensive list of .zenodo.json properties that have been tested here and found to be valid (except for the optional custom "publication_date", which exists in version 0.0.7, and has since been removed to simplify publishing new releases).
+Note on versioning: Zenodo gets the version numbers from the "version" property in .zenodo.json, and ignores any version numbers put into git tags or GitHub release names. Although this can be annoying (as it requires the user to update the version number in multiple places), it can be a useful feature for updating metadata in cases where the data itself was not changed, as the metadata can be updated and put into a new Zenodo release without having to increment the dataset's version number via the JSON.
+
+For the most comprehensive list of .zenodo.json properties that have been tested here and found to be valid, please see the latest (non-pre) Release here that also appears on the Zenodo page. In addition, version 0.0.7 also contains an optional custom "publication_date", which has been removed from subsequent releases to simplify their publication. Past releases that failed to post to Zenodo (or that posted incorrectly) will be marked as such in this GitHub repository after the fact, but there may be a short delay before this happens.
 
 
 ### Notes on specific properties