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()". ContextAwarePluginAssignmentTrait and StringTranslationTrait both supply a t() method, and the collision was resolved with an explicit insteadof. Landed as f4e7615, credit lawxen.
  • #3531242 — the missing : void return type on submitConfigurationForm(). Drupal 11.2 declared that return type on BlockBase, which made the untyped override in this module a fatal at class load and stopped drush updatedb outright. Core reverted the declaration in 11.3, so the fatal is specific to 11.2.x. Landed as 039cb78, credit Seth Hill.
  • #3614068 — the orphaned image component configuration. Landed as a2ff2bf via 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_component had no schema definition at all on this branch, so the settings form was writing a config object that nothing described.
  • layout_builder_kit.settings was declared type: config_entity when 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.

Command icon 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

aangel created an issue. See original summary.

aangel’s picture

Issue summary: View changes
aangel’s picture

The 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:

Layout Builder Kit 3.0.0, 2026-07-31
------------------------------------

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.

  • aangel committed 58193de7 on 3.0.x
    Issue #3614258 by aangel: Add CHANGELOG entry for 3.0.0
    

  • aangel committed bc7bdbd3 on 3.0.x
    Issue #3614258 by aangel: Update the 3.0.0 changelog date to the actual...