72 lines
3.3 KiB
YAML
72 lines
3.3 KiB
YAML
uuid:
|
|
- value: 09f421c4-eff1-4b5c-a692-45dfbd837758
|
|
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:16+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: 'Regularly releasing open-source software'
|
|
created:
|
|
- value: '2024-04-16T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:16+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2024/04/16/regularly-releasing-open-source-software
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>As with client applications, I recommend releasing new versions of open-source software as often as possible.</p>
|
|
|
|
<p>This makes it easier for users to update to newer versions as they can easily see the changes, and less risky as it's easier to roll back or diagnose the problem if there is an issue.</p>
|
|
|
|
<p>If you've added a feature or fixed a bug, fewer people will likely use it if it's not within a released version of your project and sat on a development branch or waiting for a tagged release. This means they're not benefiting from the changes and getting value from them.</p>
|
|
|
|
<p>You can add feature flags to hide work-in-progress features that you don't want people to use yet, but you don't want to block yourself from releasing a new version until it's complete.</p>
|
|
|
|
<p>Regular releases encourage smaller and simpler changes rather than larger and more complex - and potentially breaking - changes.</p>
|
|
|
|
<p>I like to have a release day each month to release new versions of my open-source projects, which works well for me.</p>
|
|
|
|
<p>I have a recurring task on my To Do list to review my projects and tag and release any new versions that are needed.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>As with client applications, I recommend releasing new versions of open-source software as often as possible.</p>
|
|
|
|
<p>This makes it easier for users to update to newer versions as they can easily see the changes, and less risky as it's easier to roll back or diagnose the problem if there is an issue.</p>
|
|
|
|
<p>If you've added a feature or fixed a bug, fewer people will likely use it if it's not within a released version of your project and sat on a development branch or waiting for a tagged release. This means they're not benefiting from the changes and getting value from them.</p>
|
|
|
|
<p>You can add feature flags to hide work-in-progress features that you don't want people to use yet, but you don't want to block yourself from releasing a new version until it's complete.</p>
|
|
|
|
<p>Regular releases encourage smaller and simpler changes rather than larger and more complex - and potentially breaking - changes.</p>
|
|
|
|
<p>I like to have a release day each month to release new versions of my open-source projects, which works well for me.</p>
|
|
|
|
<p>I have a recurring task on my To Do list to review my projects and tag and release any new versions that are needed.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|