Merge branch 'wdl-1.2' into 296-exponentiation

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,3 +1,4 @@
 
 ### Checklist
 - [ ] Pull request details were added to CHANGELOG.md
+- [ ] Valid examples WDL's were added or updated to the SPEC.md (see the [guide](https://github.com/openwdl/wdl-tests/blob/main/docs/MarkdownTests.md) on writing markdown tests)

CHANGELOG.md

@@ -42,23 +42,42 @@ version development
   consist of multiple files.
   [PR 241](https://github.com/openwdl/wdl/pull/241) by @cjllanwarne.
 
+
 version 1.2.0
 ---------------------------
 
++ Introduced the concept of "scoped types" to support the use of object-like values within the `hints` section while still keeping the `Object` type as deprecated.
+
++ Added new task `requirements` and `hints` sections (#540 and #541), and deprecated the `runtime` section
+
++ Added new workflow `hints` section (#543), and moved `allowNestedInputs` from workflow `meta` to `hints`
+
++ Deprecated the previously allowed behavior implied by setting `allowNestedInputs: true` where required task/subworkflow inputs could be left unsatisfied. Now all inputs either need to have a default value or have their value specified in the call inputs. Only optional task/subworkflow inputs that are not explicitly set in the call inputs may have their value set at runtime if the `allow_nested_inputs` hint is `true`.
+
++ Added `fpga` requirement and reserved hint for requesting FPGA resources.
+
++ Added `disks` and `gpu` reserved hints for requesting specific resources.
+
++ Added `contains_key` function to standard library. [PR 603](https://github.com/openwdl/wdl/pull/603)
+
 + Added exponentiation operator (`**`).
 
+
 version 1.1.1
 ---------------------------
 
 + Applied [Errata](https://github.com/openwdl/wdl/blob/main/versions/1.1/Errata.md) to the 1.1.0 spec.
 
++ Updated most examples to adhere to the new specification for WDL tests.
+
 + Added missing `File` and `version` keywords to the list of reserved words.
 
 + Added new sections or materially expanded existing sections:
   + "Limited exceptions" to type coercion rules
   + "Static Analysis and Dynamic Evaluation"
   + "Task Input Localization"
   + "Expression Placeholders" under "Command Section"
+  + Hidden types
 
 + Reformatted all tables.
 

RFC.md

@@ -3,7 +3,7 @@ RFC Process
 
 Most technical decisions are decided through the "RFC" ([Request for Comments](https://en.wikipedia.org/wiki/Request_for_Comments)) process. Small changes, such as minor grammatical edits to the specification, do not need to need to follow the RFC process. However, if one intends to make a substantive change to the WDL specification , the following process should be adhered to:
 
- 1. Ideally have an informal discussion of the topic on the [mailing list](https://groups.google.com/forum/#!forum/openwdl) and/or the [gitter channel](https://gitter.im/openwdl/wdl) in order to gauge basic viability. As a rule of thumb, receiving encouraging feedback from long-standing community members is a good indication that the RFC is worth pursuing.
+ 1. Ideally have an informal discussion of the topic on [Slack](https://join.slack.com/t/openwdl/shared_invite/zt-ctmj4mhf-cFBNxIiZYs6SY9HgM9UAVw) and/or [GitHub discussions](https://github.com/openwdl/wdl/discussions) in order to gauge basic viability. As a rule of thumb, receiving encouraging feedback from long-standing community members is a good indication that the RFC is worth pursuing.
  2. Write up a formal proposal, including requested changes to the current specification, as a pull request on GitHub
  3. A core team member will be assigned as the *shepherd* of this RFC. The shepherd shall be responsible for keeping the discussion moving and ensuring all concerns are responded to.
  4. Work to build broad support from the community. Encouraging people to comment, show support, show dissent, etc. Ultimately the level of community support for a change will decide its fate.