Release v2.3.0 (#404)

ChangeLog.md

@@ -11,13 +11,24 @@ GitHub release pages and in the git history.
 
 ## \[Unreleased\]
 
+## v2.3.0 (27 Jan. 2024)
+
 ### Features
 
 - Version is now calculated dynamically from commit information
   - `version` is the `X.Y.Z` version format of Spglib
   - `version_full` is the full version formatted like `guess-next-dev` from [setuptools-scm]
   - `commit` is the commit used when building the Spglib library
 
+### Fixes (layer group)
+
+- [\[#378\]](https://github.com/spglib/spglib/pull/378) - fix(database): add missing unique axis choices
+- [\[#379\]](https://github.com/spglib/spglib/pull/379) - fix #377 (symmetry): fix matrix pattern for layer groups
+
+### Fixes (magnetic space group)
+
+- [\[#382\]](https://github.com/spglib/spglib/pull/382) - Fix comparison of translation parts in MSG type identification
+
 ### CMake interface
 
 - Exporting `Spglib_VERSION_FULL` and `Spglib_COMMIT` CMake variables
@@ -28,18 +39,37 @@ GitHub release pages and in the git history.
 
 ### Python interface
 
-- Dropped Python 3.7 support
-- Dropped ASE Atoms-like input
+- [\[#376\]](https://github.com/spglib/spglib/pull/376) Dropped Python 3.7 support
+- [\[#386\]](https://github.com/spglib/spglib/pull/386) - Drop ASE Atoms-style input
 - Deprecating `get_version` in favor of `__version__` and `get_spg_version`
 - Added `spg_get_version`, `spg_get_version_full`, `spg_get_commit` to get the version/commit of the spglib C library
   that is being used by the binding
 - `__version__` now reports the version of the python interface
 
 ### Fortran interface
 
-- Added `spg_get_version`, `spg_get_version_full`, `spg_get_commit` to get the version/commit of the spglib C library
-  that is being used by the binding
-- Added `version`, `version_full`, `commit` variables containing the version/commit of the Fortran bindings
+- [\[#396\]](https://github.com/spglib/spglib/pull/396) - feat: Reorganize Fortran interface
+  - Added `spg_get_version`, `spg_get_version_full`, `spg_get_commit` to get the version/commit of the spglib C library
+    that is being used by the binding
+  - Added `version`, `version_full`, `commit` variables containing the version/commit of the Fortran bindings
+
+### Documentation
+
+- [\[#361\]](https://github.com/spglib/spglib/pull/361) - ci: Add doc-test
+- [\[#387\]](https://github.com/spglib/spglib/pull/387) - Merge and migrate Python API documents into docstring
+- [\[#391\]](https://github.com/spglib/spglib/pull/391) - Fix quick for autodoc2 render plugin
+- [\[#401\]](https://github.com/spglib/spglib/pull/401) - fix: RTD build
+
+### Refactoring
+
+- [\[#271\]](https://github.com/spglib/spglib/pull/271) - Fully dynamic version from git-tag
+- [\[#392\]](https://github.com/spglib/spglib/pull/392) - Replace linter and formatter with ruff and mypy
+
+### CI
+
+- [\[#356\]](https://github.com/spglib/spglib/pull/356) - Use downstream tmt tests
+- [\[#362\]](https://github.com/spglib/spglib/pull/362) - ci: Reorganize CI
+- [\[#393\]](https://github.com/spglib/spglib/pull/393) - ci: Enable testing for Fedora 38
 
 ## v2.2.0 (6 Dec. 2023)
 

Contributing.md

@@ -33,15 +33,11 @@ standard changes.
 
 ## Releasing a new Spglib version
 
-1. Update [`doc/release.md`](doc/releases.md)
-2. Increment version in [`CMakeLists.txt`](CMakeLists.txt) and [`pyproject.toml`](pyproject.toml)
-3. Push a corresponding tag, or notify the contributors of the request
-   - For official release, push a tag with the appropriate version written in `CMakeLists.txt`, e.g. `v2.1.0`.
+1. Update [`ChangeLog.md`](ChangeLog.md)
+2. Push a corresponding tag, or notify the contributors of the request
+   - For official release, push a tag with the appropriate version, e.g. `v2.1.0`.
      - This will update the release package on PyPI.
    - For pre-releases, include a `-rcX` suffix to the tag, e.g. `v2.1.0-rc1`.
-     - Keep the `pyproject.toml` version synchronized with the tag to be correctly reflected on PyPI and Conda, but
-       do
-       not update the `CMakeLists.txt` file.
      - This will update the package on TestPyPI automatically
    - For testing, you can push a tag with suffix `-test` to your personal fork, or create a PR to `test-PyPi-action`
      branch
@@ -51,12 +47,10 @@ standard changes.
      - If you are using the PR approach to `test-PyPi-action` approach, make sure to change the target branch at the
        end
      - This will not attempt to upload to PyPI, but the artifacts will still be generated.
-4. Notify the packaging contributors
+3. Notify the packaging contributors
 
 Note that scikit-build-core does not yet support dynamic variables for the
 updating `pyproject.toml` (follow progress at the upstream issues
 [#172](https://github.com/scikit-build/scikit-build-core/issues/172) and
 [#116](https://github.com/scikit-build/scikit-build-core/issues/116)).
-Currently, the Pypi release versions and releases candidates have to be
-manually updated in the version field of the [`pyproject.toml`](pyproject.toml)
-file.
+Currently, the PyPI release versions and releases candidates is dynamically calculated from commit tag.