Problem/Motivation
Three fixes have landed on the 3.0.x branch since the 3.0.0-beta2 release and are all currently unreleased. CHANGELOG.txt has no entry for them, so anyone reading the file has no way to tell what is on the branch beyond beta2. The changelog entry should be in place before the next 3.0.x release is cut.
The unreleased fixes are:
- #3459820 — "Call to protected method t()".
ContextAwarePluginAssignmentTraitandStringTranslationTraitboth supply at()method, and the collision was resolved with an explicitinsteadof. Landed asf4e7615, credit lawxen. - #3531242 — the missing
: voidreturn type onsubmitConfigurationForm(). Drupal 11.2 declared that return type onBlockBase, which made the untyped override in this module a fatal at class load and stoppeddrush updatedboutright. Core reverted the declaration in 11.3, so the fatal is specific to 11.2.x. Landed as039cb78, credit Seth Hill. - #3614068 — the orphaned image component configuration. Landed as
a2ff2bfvia merge request !14.
Three further items belong in the changelog but are not the subject of any issue of their own, so the changelog is the only place a user would learn about them. Two were found while fixing #3614068:
layout_builder_kit.image_componenthad no schema definition at all on this branch, so the settings form was writing a config object that nothing described.layout_builder_kit.settingswas declaredtype: config_entitywhen it is simple config.
And separately: the test suite had never actually executed. Both test files carried a plural Tests suffix, which PHPUnit's *Test.php discovery does not collect, so the suite silently ran nothing.
Steps to reproduce
Check out the 3.0.x branch and read CHANGELOG.txt: the newest entry is 3.0.0-beta2, while git log shows the three fixes above sitting on the branch unreleased and undocumented.
Proposed resolution
Add a CHANGELOG.txt entry to 3.0.x covering the fixes and the undocumented findings listed above. Documentation only — no code changes, no behaviour change.
On the version number: the entry is written as 3.0.0 — a stable release. The entry was originally drafted as 3.0.0-beta3, continuing the existing beta track, but the maintainer has decided to cut 3.0.0 stable instead, and the merge request has been amended accordingly.
One consequence of going stable: Drupal's security advisory policy only covers projects that have a stable release. Every layout_builder_kit release to date has been alpha or beta, so the project currently sits outside that policy. Tagging 3.0.0 stable brings 3.0.x under security team coverage, which changes how any future security-relevant bug must be handled: it would need to be reported privately through the security advisory process rather than in the public issue queue.
Remaining tasks
- Tag the 3.0.0 stable release (maintainer).
- Review and merge the issue fork merge request.
User interface changes
None.
API changes
None.
Data model changes
None.
Issue fork layout_builder_kit-3614258
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
aangel commentedComment #4
aangel commentedThe CHANGELOG entry and MR !20 now read 3.0.0 rather than 3.0.0-beta3.
The entry was originally drafted as 3.0.0-beta3 simply to continue the existing beta track — every release of this project so far has been alpha or beta, and nothing in these three fixes by itself amounts to a stability claim. The maintainer has decided instead to cut 3.0.0 stable. The single commit on the issue fork has been amended in place (no second commit), so the MR is still one clean commit, and the heading now reads:
The bullet list describing the three fixes is unchanged.
One consequence worth flagging explicitly
Drupal's security advisory policy only covers projects that have a stable release. Because every layout_builder_kit release to date has been alpha or beta, the project currently sits outside that policy. Tagging 3.0.0 stable brings 3.0.x under security team coverage, and that changes how any future security-relevant bug has to be handled: it must be reported privately through the security advisory process rather than discussed and fixed in the public issue queue.
For a concrete sense of what that means in practice: the image-configuration bug just fixed in #3614068 — which left file-extension validation NULL on fresh installs, so an upload field shipped with no extension restriction until an administrator happened to save the settings form — is exactly the class of thing that would have been an SA matter under coverage, rather than an ordinary public bug report.
This is not an argument against releasing stable. It is a change in obligations that is easy to miss and hard to reverse, so it should be a deliberate opt-in rather than a side effect of the version number.
No merge, no tag, and no release node has been created here — that is the maintainer's call.