76 lines
3 KiB
YAML
76 lines
3 KiB
YAML
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
|