oliverdavies.uk/content/node.0c66d8de-6dbd-4ab1-b40f-29276d7af5f1.yml

82 lines
3.9 KiB
YAML

uuid:
- value: 0c66d8de-6dbd-4ab1-b40f-29276d7af5f1
langcode:
- value: en
type:
- target_id: daily_email
target_type: node_type
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
revision_timestamp:
- value: '2025-06-20T22:34:48+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: 'Refactoring, semantic versioning and backward compatibility'
created:
- value: '2025-06-16T22:32:33+00:00'
changed:
- value: '2025-06-20T22:34:48+00:00'
promote:
- value: false
sticky:
- value: false
default_langcode:
- value: true
revision_translation_affected:
- value: true
path:
- alias: /daily/2025/06/16/refactoring-semantic-versioning-and-backward-compatibility
langcode: en
body:
- value: |-
There's an approach to refactoring I've seen in a number of open source projects, including Symfony and Drupal.
In Drupal 7 and earlier, there were only minor version releases.
Drupal 7 started at 7.0 and ended at 7.103.
Code could be refactored, but it still needed to be backward compatible so existing code couldn't be removed.
Now, many projects have adopted semantic versioning that contain major, minor and patch versions, like Drupal 11.2.0.
Minor and patch versions are backward compatible, but major versions - such as Drupal 10 and 11 - can break backward compatibility.
This means old code can be removed and the codebase can be tidied.
A good example of this was the `drupal_set_message()` function that was replaced by the `Messenger` service.
The original code was moved, the function was changed to use the new service and the function was marked as deprecated.
If you used it, you were notified it would be removed in the next major version.
It still worked so was still backward compatible.
When the next major version was released, the old function was removed as backward compatibility could be broken.
I like this approach as it means code can be refactored and improved, users are given time to update their code, new features can be continuously added, and the main codebase is kept clean and avoids a lot of legacy code.
format: markdown
processed: |
<p>There's an approach to refactoring I've seen in a number of open source projects, including Symfony and Drupal.</p>
<p>In Drupal 7 and earlier, there were only minor version releases.</p>
<p>Drupal 7 started at 7.0 and ended at 7.103.</p>
<p>Code could be refactored, but it still needed to be backward compatible so existing code couldn't be removed.</p>
<p>Now, many projects have adopted semantic versioning that contain major, minor and patch versions, like Drupal 11.2.0.</p>
<p>Minor and patch versions are backward compatible, but major versions - such as Drupal 10 and 11 - can break backward compatibility.</p>
<p>This means old code can be removed and the codebase can be tidied.</p>
<p>A good example of this was the <code>drupal_set_message()</code> function that was replaced by the <code>Messenger</code> service.</p>
<p>The original code was moved, the function was changed to use the new service and the function was marked as deprecated.</p>
<p>If you used it, you were notified it would be removed in the next major version.</p>
<p>It still worked so was still backward compatible.</p>
<p>When the next major version was released, the old function was removed as backward compatibility could be broken.</p>
<p>I like this approach as it means code can be refactored and improved, users are given time to update their code, new features can be continuously added, and the main codebase is kept clean and avoids a lot of legacy code.</p>
summary: ''
field_daily_email_cta:
- target_type: node
target_uuid: 3074e1e9-c691-4f73-a71c-cfe5920f884e