Br v4.0.0

NEWS.md

@@ -1,3 +1,13 @@
+# v4.0.0
+
+* BREAKING CHANGE: Introduction of `is_required` boolean property at the `output_type` level to configure whether the output type is required for submissions to be considered valid (#99). 
+* BREAKING CHANGE: Disallowed `optional` property in `output_type_id` objects. As such, when a given output type is submitted, values for all output type IDs much be submitted (#100,#101, #102).
+* BREAKING CHANGE: To improve cross-platform interoperability, expectation of missing values in point estimate `output_type_id` `required` properties now encoded with `null` instead of `["NA"]` (#109). 
+* Introduction of optional `derived_task_ids` properties to enable hub administrators to define derived task IDs (i.e. task IDs whose values depend on the values of other task IDs). The higher level `derived_task_ids` property sets the property globally at the hub level but can be overriden by the round level `derived_task_ids` property. The property allows for primarily validation functionality to ignore such task IDs when appropriate which can significantly improve validation efficency (#96). For more information see [`hubValidations` documentation on ignoring derived task IDs](https://hubverse-org.github.io/hubValidations/articles/validate-pr.html#ignoring-derived-task-ids-to-improve-performance).
+* Added more specific schema for `target_keys` to ensure only `string` properties are allowed (#97)
+* Removed the requirement for a minimum value of zero in `cdf` numeric `output_type_id`s (#113).
+* Ensured that additional properties are not allowed in lower level properties (e.g. individual task IDs, `output_type` objects etc). Custom additional properties are only allowed at the `round` level, while additional task ID objects that match the expected task ID schema are allowed in the `task_ids` object (#114).
+
 # v3.0.1
 
 * Introduction of optional `output_type_id_datatype` property to enable hub administrators to configure and communicate the `output_type_id` column data type at a hub level. This will allow hubs to override default behaviour of automatically determinining the simplest data type that can accomodate output type IDs across all output types when creating hub schema. The setting is also useful for administrators to future proof the `output_type_id` column from potential issues arising by changes in data type, introduced by new output types after submissions have begun, by setting `output_type_id_datatype` to the simplest data type from the start, i.e. character (#87).

README.md

@@ -23,7 +23,7 @@ After making a new release to the schema repository, ensure `hubDocs` are also a
 
 ## New schema version development process
 
-- New schema versions should be developed in a separate branch. Name the branch `v{version-number}-branch` to avoid creating release tags which share the same name as a branch later on.
+- New schema versions should be developed in a separate branch. Name the branch `br-v{version-number}` to avoid creating release tags which share the same name as a branch later on.
 - New version branches should be merged into `main` when ready to released.
 - Merging into `main` should be accompanied by creating an associated formal release in the repository.
 - Re-run all tests in `hubAdmin`, address any introduced problems and update snapshots to latest schema version.