1
0

changelog.rst 2.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990
  1. .. _changelog:
  2. =========
  3. Changelog
  4. =========
  5. With the addition of `SEP 01`_ the `keepachangelog`_ format was introduced into
  6. our CHANGELOG.md file. The Salt project is using the `towncrier`_ tool to manage
  7. the CHANGELOG.md file. The reason this tool was added to manage the changelog
  8. was because we were previously managing the file manually and it would cause
  9. many merge conflicts. This tool allows us to add changelog entries into separate
  10. files and before a release we simply need to run ``towncrier --version=<version>``
  11. for it to compile the changelog correctly.
  12. .. _add-changelog:
  13. How do I add a changelog entry
  14. ------------------------------
  15. To add a changelog entry you will need to add a file in the `changelog` directory.
  16. The file name should follow the syntax ``<issue #>.<type>``.
  17. The types are in alignment with keepachangelog:
  18. removed:
  19. any features that have been removed
  20. deprecated:
  21. any features that will soon be removed
  22. changed:
  23. any changes in current existing features
  24. fixed:
  25. any bug fixes
  26. added:
  27. any new features added
  28. For example if you are fixing a bug for issue number #1234 your filename would
  29. look like this: changelog/1234.fixed. The contents of the file should contain
  30. a summary of what you are fixing. If there is a legitimate reason to not include
  31. an issue number with a given contribution you can add the PR number as the file
  32. name (``<PR #>.<type>``).
  33. If your PR does not align with any of the types, then you do not need to add a
  34. changelog entry.
  35. .. _generate-changelog:
  36. How to generate the changelog
  37. -----------------------------
  38. This step is only used when we need to generate the changelog right before releasing.
  39. You should NOT run towncrier on your PR, unless you are preparing the final PR
  40. to update the changelog before a release.
  41. You can run the `towncrier` tool directly or you can use nox to help run the command
  42. and ensure towncrier is installed in a virtual environment. The instructions below
  43. will detail both approaches.
  44. If you want to see what output towncrier will produce before generating the change log
  45. you can run towncrier in draft mode:
  46. .. code-block:: bash
  47. towncrier --draft --version=3001
  48. .. code-block:: bash
  49. nox -e 'changelog(draft=True)' -- 3000.1
  50. Version will need to be set to whichever version we are about to release. Once you are
  51. confident the draft output looks correct you can now generate the changelog by running:
  52. .. code-block:: bash
  53. towncrier --version=3001
  54. .. code-block:: bash
  55. nox -e 'changelog(draft=False)' -- 3000.1
  56. After this is run towncrier will automatically remove all the files in the changelog directory.
  57. .. _`SEP 01`: https://github.com/saltstack/salt-enhancement-proposals/pull/2
  58. .. _`keepachangelog`: https://keepachangelog.com/en/1.0.0/
  59. .. _`towncrier`: https://pypi.org/project/towncrier/