@@ -34,15 +34,12 @@ open issues against the milestone.
34
34
* ** Agreement from core team** : The core STAC team should meet (on phone or on gitter) and decided that the release is ready.
35
35
This should include review of the issues, as well as looking at the spec holistically, to make sure the new changes keep
36
36
with a coherent whole.
37
- * ** Validate Examples** : All examples given in the specification should be programmatically validated against their relevant
38
- schema. For 0.6.0-RC1 and before this is a manual process, but with CirclCI in place this should happen automatically. But
39
- someone should still review that all the schemas have been updated and align with the current state of the spec, as that
40
- can not happen automatically.
41
37
* ** Final Spec Read Through** : There should be a final read through of the core specification to make sure it makes sense
42
38
and there are no typos, errors, etc.
43
39
* ** Update the version numbers** : There are several places in the spec that use the version number or a branch name in text
44
40
or a link. These include the markdown files and the JSON schemas. Right now the best thing to do is just a search & replace
45
- for the last version number and ` https://schemas.stacspec.org/dev/ ` (in JSON Schemas, don't replace it here).
41
+ for the last version number and ` https://schemas.stacspec.org/dev/ ` with ` https://schemas.stacspec.org/<release-version>/ `
42
+ (in JSON Schemas, don't replace it here). ` <release-version> ` must correspond with the tag on GitHub, usually including a leading ` v ` .
46
43
Hopefully in the future there will be scripts to do this.
47
44
* ** Update the Changelog** : The [ changelog] ( CHANGELOG.md ) should be reviewed to make sure it includes all major improvements
48
45
in the release. And anything in 'unreleased' section should move to the version of the spec to be released.
0 commit comments