101 lines
5.4 KiB
YAML
101 lines
5.4 KiB
YAML
uuid:
|
|
- value: 0d65cf74-92ad-4d03-a7d1-90a63c8a2823
|
|
langcode:
|
|
- value: en
|
|
type:
|
|
- target_id: daily_email
|
|
target_type: node_type
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
|
revision_timestamp:
|
|
- value: '2025-05-11T09:00:38+00:00'
|
|
revision_uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
revision_log: { }
|
|
status:
|
|
- value: true
|
|
uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
title:
|
|
- value: |
|
|
Why keep a Changelog?
|
|
created:
|
|
- value: '2023-06-23T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:38+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2023/06/23/why-keep-a-changelog
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<h2 id="what-is-a-changelog%3F">What is a Changelog?</h2>
|
|
|
|
<p>A Changelog is a file that documents changes made to a codebase.</p>
|
|
|
|
<p>In its simplest form, it's a plain text file within a code repository, or it can be written in Markdown or reStructuredText or kept within a separate tool like Confluence or Sharepoint. Regardless of where it's kept, the main thing is the content.</p>
|
|
|
|
<p>It's not a copy of the Git log. It's a summary of the changes to be read by humans and for them to see what's changed, not a list of Git commits.</p>
|
|
|
|
<p>If you're considering using my open-source package, you can see what changes I've released, when, and what changes are due to release.</p>
|
|
|
|
<h2 id="how-is-it-structured%3F">How is it structured?</h2>
|
|
|
|
<p>Each version should have a heading specifying the version number and/or release date and a list of changes grouped by their type - whether something was added, changed, deprecated, removed, etc. This works well if you use conventional commits!</p>
|
|
|
|
<p>I like to follow a format called <a href="https://keepachangelog.com">Keep a Changelog</a>.</p>
|
|
|
|
<p>The headings link to a diff so you can see all of the commits and changes made to the code, and there's an <code>Unreleased</code> section that shows commits that have yet to be tagged and released.</p>
|
|
|
|
<p>If you need to present changes to a review or approval board, having an easy-to-read list of changes, separated by their type, is a much clearer format than a list of Git commits.</p>
|
|
|
|
<h2 id="when-should-it-be-updated%3F">When should it be updated?</h2>
|
|
|
|
<p>I recommend continually updating the Changelog rather than leaving it to just before a deployment. It's quick to add it to the <code>Unreleased</code> section as part of the commit and update the headings later.</p>
|
|
|
|
<h2 id="can-i-see-an-example%3F">Can I see an example?</h2>
|
|
|
|
<p>Sure. See the one I added to the <a href="https://github.com/opdavies/national-rail-enquiries-feed-parser/blob/main/CHANGELOG.md">National Rail Enquiries feed parser library</a> I've been working on or the <a href="https://git.drupalcode.org/project/tailwindcss/-/blob/5.x/CHANGELOG.md">Tailwind CSS starter kit theme for Drupal</a>.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<h2 id="what-is-a-changelog%3F">What is a Changelog?</h2>
|
|
|
|
<p>A Changelog is a file that documents changes made to a codebase.</p>
|
|
|
|
<p>In its simplest form, it's a plain text file within a code repository, or it can be written in Markdown or reStructuredText or kept within a separate tool like Confluence or Sharepoint. Regardless of where it's kept, the main thing is the content.</p>
|
|
|
|
<p>It's not a copy of the Git log. It's a summary of the changes to be read by humans and for them to see what's changed, not a list of Git commits.</p>
|
|
|
|
<p>If you're considering using my open-source package, you can see what changes I've released, when, and what changes are due to release.</p>
|
|
|
|
<h2 id="how-is-it-structured%3F">How is it structured?</h2>
|
|
|
|
<p>Each version should have a heading specifying the version number and/or release date and a list of changes grouped by their type - whether something was added, changed, deprecated, removed, etc. This works well if you use conventional commits!</p>
|
|
|
|
<p>I like to follow a format called <a href="https://keepachangelog.com">Keep a Changelog</a>.</p>
|
|
|
|
<p>The headings link to a diff so you can see all of the commits and changes made to the code, and there's an <code>Unreleased</code> section that shows commits that have yet to be tagged and released.</p>
|
|
|
|
<p>If you need to present changes to a review or approval board, having an easy-to-read list of changes, separated by their type, is a much clearer format than a list of Git commits.</p>
|
|
|
|
<h2 id="when-should-it-be-updated%3F">When should it be updated?</h2>
|
|
|
|
<p>I recommend continually updating the Changelog rather than leaving it to just before a deployment. It's quick to add it to the <code>Unreleased</code> section as part of the commit and update the headings later.</p>
|
|
|
|
<h2 id="can-i-see-an-example%3F">Can I see an example?</h2>
|
|
|
|
<p>Sure. See the one I added to the <a href="https://github.com/opdavies/national-rail-enquiries-feed-parser/blob/main/CHANGELOG.md">National Rail Enquiries feed parser library</a> I've been working on or the <a href="https://git.drupalcode.org/project/tailwindcss/-/blob/5.x/CHANGELOG.md">Tailwind CSS starter kit theme for Drupal</a>.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|