Prepare 1.3.0-rc.1 release candidate

AUTHORS

@@ -6,6 +6,8 @@ The OPTIMADE API has been developed with contributions by the participants of th
 - the CECAM in Lausanne, Switzerland (virtually) 2021-06-07 to 2021-06-11
 - the CECAM in Lausanne, Switzerland 2022-05-30 to 2022-06-03
 - the CECAM in Lausanne, Switzerland 2023-06-05 to 2023-06-09
+- the CECAM in Lausanne, Switzerland 2024-06-10 to 2024-06-14
+- the Vilnius University Life Sciences Center in Vilnius, Lithuania 2025-09-15 to 2025-09-19
 
 Initial and major contributors to the development of the OPTIMADE specification and implementation in alphabetical order:
 Casper Andersen

CHANGELOG.md

@@ -1,5 +1,48 @@
 # Changelog
 
+## v1.3.0 (November 2025)
+
+This release extends the OPTIMADE specification with new entry types and properties with an emphasis on applying the partial data protocol from v1.2 to the new trajectories endpoint, for which each resource is likely to be too large to be served in a single response.
+
+As part of this release, the OPTIMADE consortium also adopts the Contributor Covenant (3.0) Code of Conduct for all community interactions.
+Please see [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) for details of the contributor expectations, as well as reporting and enforcement procedures.
+
+Minor OPTIMADE releases are always intended to be backwards-compatible for clients, meaning that any client code written for v1.x should continue to work, and any breaking changes should be reported as bugs to be fixed in a patch v1.3.x release.
+
+## New features
+
+- **Trajectories endpoint** ([#377](https://github.com/Materials-Consortia/OPTIMADE/pull/377)): A new trajectories entry type has been added to the specification to share data belonging to ordered sequences of structures, such as those arising from molecular dynamics simulations or geometry optimizations.
+    In order to handle large individual entries, this endpoint makes use of the partial data protocol introduced in v1.2, with additional specialisations for slicing (`query_slices` URL parameter) and representing dimensions that remain constant throughout a trajectory, whilst retaining the ability to filter using the normal OPTIMADE syntax via the `reference_frame` field.
+- **Provider-specific data types** ([#560](https://github.com/Materials-Consortia/OPTIMADE/pull/560)): Providers and namespaces can now define custom data types for their properties that let
+  them use specific query semantics that differ from the standard OPTIMADE data
+  types.
+  For example, a provider could define a field that uses a string format for a
+  field, but a custom data type that allows for e.g., `CONTAINS` queries to do
+  something other than pure substring matching.
+- **New fields for structures entries (`fractional_site_positions`, `site_coordinate_span`, `site_coordinate_span_description`, `optimization_type`, `wyckoff_positions`)**
+  ([#539](https://github.com/Materials-Consortia/OPTIMADE/pull/539), [#562](https://github.com/Materials-Consortia/OPTIMADE/pull/562), [#570](https://github.com/Materials-Consortia/OPTIMADE/pull/570)): Several new fields have been added to the structures entry type to improve symmetry representation and to provide information about the provenance of the structure:
+  - `fractional_site_positions`, `site_coordinate_span`,
+    `site_coordinate_span_description`: New fields that can be used to describe positions of atoms as an alternative to `cartesian_site_positions`, to be used in conjunction with `space_group_symmetry_operations_xyz` when providing only the asymmetric unit of a structure.
+    The additional `site_coordinate_span` and `site_coordinate_span_description` fields can be used to describe the extent of the atoms that have been provided as fractional coordinates and can take values such as `asymmetric_unit`, `unit_cell`, `molecular_entities`, etc.
+  - `wyckoff_positions`: This field can be used to provide the Wyckoff positions
+    of each site in the structure, if known, following the IUCr definitions of
+    labelling.
+  - `optimization_type`: This field can be used to describer the type of
+    optimization that has been performed on a structure, if any.
+    For example, the optimization could be relative to experimental evidence
+    (`experimental`) (e.g., minimising discrepancy with a diffraction pattern), relative to some
+    kind of Hamiltonian (e.g., density-funtional theory or a force-field), and
+    whether the optimisation scope was `local` or in some sense `global`
+    (minimised relative to a global energy surface of possible decompositions
+    and other structural configurations).
+- **JSONLines standardization for serializing OPTIMADE APIs to disk**
+  ([#531](https://github.com/Materials-Consortia/OPTIMADE/pull/531)): An
+  appendix has been added to the specification with a suggestion for how to serialize OPTIMADE entries, or full APIs (including e.g., info endpoints) to a single file using the [JSONLines format](https://jsonlines.org/).
+  This format is already in-use by several tools in the ecosystem and is
+  RECOMMENDED for interoperability.
+- **Roles for files** ([#523](https://github.com/Materials-Consortia/OPTIMADE/pull/523)):
+  Relationships with `files` entries can now specify a `role` that describes whether the file is an `input`, `output` with respect to an existing `calculations` entry.
+
 ## v1.2.0 (June 2024)
 
 

optimade.rst

@@ -1,6 +1,6 @@
-=========================================
-OPTIMADE API specification v1.3.0~develop
-=========================================
+=================================
+OPTIMADE API specification v1.3.0
+=================================
 
 .. comment