uuid:
  - value: f971fedc-ce38-41b4-8d1f-b37766fb06e1
langcode:
  - value: en
type:
  - target_id: daily_email
    target_type: node_type
    target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
revision_timestamp:
  - value: '2025-08-03T22:53:00+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: 'Changelogs with Continuous Delivery'
created:
  - value: '2025-07-29T22:51:45+00:00'
changed:
  - value: '2025-08-03T22:53:00+00:00'
promote:
  - value: false
sticky:
  - value: false
default_langcode:
  - value: true
revision_translation_affected:
  - value: true
path:
  - alias: ''
    pid: null
    langcode: en
body:
  - value: |-
      Over the past few days, I've written why I think it's a good idea to keep a Changelog for software projects.

      I've linked to the [Keep a Changelog][0] project, which gives a format for a Changelog file.

      In it, unreleased changes are grouped at the top, and released changes grouped by version number.

      But, how would this work if you're doing continuous delivery?

      If you're deploying once a day, it could make sense to use release versions.

      But, what if you're releasing multiple times a day, or separately releasing each commit?

      Is it beneficial to tag every commit with its own release number?

      In that situation, I've altered the format to group commits by date, and removed the Unreleased section as it's no longer needed.

      In this case, you still get the benefits of a human-readable Changelog with a simplified structure.

      I like standardisation, but use the format that works for you and your project.

      [0]: https://keepachangelog.com
    format: markdown
    processed: |
      <p>Over the past few days, I've written why I think it's a good idea to keep a Changelog for software projects.</p>
      <p>I've linked to the <a href="https://keepachangelog.com">Keep a Changelog</a> project, which gives a format for a Changelog file.</p>
      <p>In it, unreleased changes are grouped at the top, and released changes grouped by version number.</p>
      <p>But, how would this work if you're doing continuous delivery?</p>
      <p>If you're deploying once a day, it could make sense to use release versions.</p>
      <p>But, what if you're releasing multiple times a day, or separately releasing each commit?</p>
      <p>Is it beneficial to tag every commit with its own release number?</p>
      <p>In that situation, I've altered the format to group commits by date, and removed the Unreleased section as it's no longer needed.</p>
      <p>In this case, you still get the benefits of a human-readable Changelog with a simplified structure.</p>
      <p>I like standardisation, but use the format that works for you and your project.</p>
    summary: ''
field_daily_email_cta:
  - target_type: node
    target_uuid: 9b4c39a3-702f-486c-a79b-4d7b96a4f3f6