.. include:: ../../common_links.inc
.. _whats_new_contributions:
=================================
Contributing a "What's New" Entry
=================================
.. readingtime::
Please include a "What's New" changelog fragment for **any** change that you
make to Iris. **Even if it is not relevant to users** - the
`Fragment Types`_ include ``internal`` for this - the page is read by
contributors as well as users, and it reveals the work needed to keep a
project going.
Iris uses `towncrier `_ to manage changelog
entries. Each pull request adds a small file (a "fragment") to the root
``changelog/`` directory. At release time, ``towncrier`` collects the fragments
and renders the full What's New page.
See this docs section for all What's New pages: :ref:`iris_whatsnew`.
How it Works
============
Instead of editing a shared file, each contributor creates a small
reStructuredText file in the ``changelog/`` directory at the root of the
repository. This avoids the merge conflicts that were common with the
previous approach.
Creating a Fragment
===================
1. **Name your file** using the pattern::
..rst
For example, if your pull request number is ``7200`` and you are adding a
feature, create::
changelog/7200.feature.rst
.. hint::
If you have not yet created the pull request, you can guess what the
next PR number may be using::
> curl -s "https://api.github.com/repos/SciTools/iris/issues?sort=created&direction=desc&per_page=1" | jq -r '.[0].number + 1'
2. **Write a short description** of your change in the file. The content is
reStructuredText. For example::
:user:`tkknight` added a new option to :func:`iris.plot.pcolormesh`
for controlling the colorbar orientation. (:issue:`9999`)
Notes:
* Use ``:user:`github-name``` to credit contributors.
* Use ``:issue:`NNNN``` to reference issues.
* The pull request reference is added automatically by ``towncrier`` based on
the fragment filename - you do **not** need to include ``:pull:`` in your
content unless you are referencing another pull request.
* Where possible, do not exceed **column 80**.
3. **Multiple fragments per PR** are allowed if a single pull request makes
changes across different categories. For example, a PR might have both
``7200.feature.rst`` and ``7200.doc.rst``. If multiple fragments within the same
category are needed, you can append `.0.rst`, `.1.rst`, etc to the end of the file.
4. **Multiple PRs per fragment** are automatically collated by ``towncrier``.
Create separate fragment files per PR with **identical** contents.
Fragment Types
==============
The following fragment types are available, matching the rendered section
headings in the What's New page:
``announcement``
📢 General news and announcements to the Iris community.
``feature``
✨ Features that are new or changed to add functionality.
``bugfix``
🐛 A bug fix.
``breaking``
💣 A change that causes an incompatibility with prior versions of Iris.
``performance``
🚀 A performance enhancement.
``deprecation``
🔥 Deprecation of functionality.
``dependency``
🔗 Additions, removals and version changes in Iris' package dependencies.
``doc``
📚 Changes to documentation.
``internal``
💼 Changes to any internal or development related topics, such as testing,
environment dependencies etc.
Highlights
==========
The release highlights associated with a ``towncrier`` changelog are defined
in the ``docs/src/whatsnew/highlights.rst`` file.
Manually update the ``hightlights.rst`` with any notable release information
that you want to share with the community.
Previewing the Changelog
========================
You can manually preview how the changelog will render by running::
> towncrier build --draft
This will print the rendered reStructuredText to **stdout** without modifying any
files or removing fragment files.
.. note::
The reStructuredText syntax will be checked as part of building the
documentation. Any warnings should be corrected. The
`Iris GitHub Actions`_ will automatically build the documentation when
creating a pull request, however you can also manually
:ref:`build ` the documentation.
.. tip::
``towncrier`` and the
`sphinx-changlog `__
directive will automatically render the latest development changelog
whenever the documentation is built.
Building the Changelog
======================
To build the release changelog
#. Change directory to ``docs/src/whatsnew/``.
#. Ensure that the ``hightlights.rst`` is populated.
#. Create the changelog release directory e.g., ``mkdir ``.
#. Relocate the ``hightlights.rst`` i.e., ``git mv highlights.rst ``.
#. Build the changelog i.e., ``towncrier build --version ``. Note
that this will create a rendered ``/.rst`` changelog
and automatically stage this file with ``git``. The changelog news fragment
files will also be automatically removed.
#. Remove the latest development changelog i.e., ``git rm latest.rst``.
#. Update the "What's New" ``index.rst`` replacing all references to ``latest.rst``
with ``/.rst``.
.. tip::
Using the ``--keep`` command line argument when building the changelog allows
you to review the rendered release changelog and keep all the changelog news
fragment files, allowing you to backtrack and make changes, if necessary.
Configuration
=============
``towncrier`` is configured within the ``[tool.towncrier]`` table of the root
``pyproject.toml``.
The ``changelog/template.rst`` file contains the ``jinja2`` template used by
``towncrier`` to render the changelog news fragments, sections, title and
include the associated ``hightlights.rst``.