Plugin: Add requirement for minimum and maximum WordPress versions #35194

azaozz · 2021-09-28T18:50:58Z

Description

Limits loading of Gutenberg when the WordPress version is too old or too new. This will prevent errors and incompatibilities in the future. When the plugin is not loaded it asks the user to either turn plugin auto-updates on, update the plugin, or upgrade WordPress (if they can).

When running a newer development version of WP Gutenberg is loaded and adds a warning that it needs updating and will stop working after WordPress is upgraded to the next release version.

Adds GUTENBERG_MIN_WP_VERSION and GUTENBERG_MAX_WP_VERSION constants.
Adds couple more warnings when Gutenberg is too old or too new for the WP installation.
Adds warnings in the plugins list table row when the plugin is not loaded.

To test: override $wp_version in wp-includes/version.php (better) or change the requirements in gutenberg_pre_init().

(The error/warning strings can probably be enhanced. Edit as you see fit.)

Checklist:

My code is tested.
My code follows the WordPress code style.
My code follows the accessibility standards.
I've tested my changes with keyboard and screen readers.
My code has proper inline documentation.
I've included developer documentation if appropriate.
I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).

Nikschavan

Noticed some minor typos

gutenberg.php

gziolo · 2023-10-10T07:12:14Z

gutenberg.php

-gutenberg_pre_init();
+// Minimum supported version. Has to match "Requires at least" header above.
+if ( ! defined( 'GUTENBERG_MIN_WP_VERSION' ) ) {
+	define( 'GUTENBERG_MIN_WP_VERSION', '5.7' );


We could auto-generate this constant. This would be similar to how GUTENBERG_VERSION gets injected when building the plugin zip:

gutenberg/bin/generate-gutenberg-php.php

Lines 35 to 40 in d55093a

if (

! $plugin_version &&

preg_match( '@^\s*\*\s*Version:\s*([0-9.]+)@', $line, $matches )

) {

$plugin_version = $matches[1];

}

Yep, has to match the Requires at least from the plugin's headers (top of this file). No need to type it twice :)

gziolo · 2023-10-10T07:17:01Z

gutenberg.php

+	// Also note that `version_compare()` considers 1 < 1.0 < 1.0.0 (before suffixes)
+	// so 6.0 < 6.0.0-alpha and 6.0-beta < 6.0.0-alpha are both true. For that reason
+	// the constant should be set to major (two digits) WordPress version.
+	define( 'GUTENBERG_NEXT_UNSUPPORTED_WP_VERSION', '6.0' );


It might be risky, but maybe we could also auto-generate this constant from Tested up to:

gutenberg/readme.txt

Line 3 in 1d0f3c4

Tested up to: 6.3

Yea, was thinking the same. Generally the Tested up to is set to the currently released WP version, will need to increment it.

Was wondering, what would be a good rule-of-thumb max WP version? As far as I see fixes and new features that get added to Gutenberg while WP is in alpha are generally synced (merged) with core trunk before WP is released, i.e. in the same WP version. The question is: should it stop loading Gutenberg if WP is newer than the Tested up to +1, or should it just show a warning to update Gutenberg in Tested up to +2, and stop loading in Tested up to +3?

It might be risky, but maybe...

Looking a bit more, actually not sure this would work well. The problem is that if Gutenberg is released during WP alpha or (early?) beta, this should be set to Tested up to +1. However if Gutenberg is released during WP RC, this should probably be set to Tested up to +2 as any new features or bugfixes will most likely not be added to the WP RC branch (branching of WP trunk usually happens shortly after RC1). So seems this would have to be set manually. Of course there will be a lengthily explanation in inline comments about how to do it.

Right, it's very difficult to reason how that could work. I need to think a bit more about all the relations between the Gutenberg versions backported to the given major version of WordPress core, Tested up to, the release process, etc. The goal from my perspective would be to automate as much as possible so people don't have to go through the same painful process again reasoning about all the implications 😄

people don't have to go through the same painful process again reasoning about all the implications

Yea, automating the decision would be best. Not sure if that would be possible though, seems too many variables and possible exceptions. The next best thing would be to add as much help and explanations as possible. Thinking it would be great to have "couple pages long" docblock there, in any case.

gziolo · 2023-10-10T07:20:26Z

It would be a very useful addition for sites using the Gutenberg plugin. In particular, it would help avoid the situation when the plugin downgrades the version of the editor that is shipped in WordPress core.

github-actions · 2023-10-12T22:19:10Z

Flaky tests detected in ddc4ce3.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6974358369
📝 Reported issues:

[Flaky Test] can be created by selecting text and using keyboard shortcuts #48387 in /test/e2e/specs/editor/blocks/links.spec.js
[Flaky Test] should insert elements from multiple completers in a single block #47916 in /test/e2e/specs/editor/various/autocomplete-and-mentions.spec.js

gziolo · 2023-10-13T08:43:36Z

gutenberg.php

+/**
+ * Add a "Gutenberg version is too old" plugins list table notice.
+ *
+ * @since 11.7.0


This PR has been open for quite some time. These number will need to be updated before landing 😄

Yep, still going through it at the moment. Should have a better/cleaned up version by tonight.

azaozz · 2023-10-13T23:53:22Z

Warnings and error messages (suggestions for improving the text welcome):

WPprodigy · 2023-10-25T15:50:10Z

Related trac ticket: https://core.trac.wordpress.org/ticket/59720

gutenberg.php

youknowriad · 2023-10-26T09:31:47Z

gutenberg.php

+	} elseif (
+		version_compare( $wp_version, $max_supported_version, '<' ) &&
+		version_compare( $wp_version, $max_supported_version . '-alpha', '>=' )
+	) {


To test this I set the WP max version to 6.3 and I have 6.4 (beta or RC) installed locally, and I expected the plugin to disable entirely, but for now I just got that it will be disabled when I upgrade. To be honest, I think that's a bit confusing and I'd just disable Gutenberg in this case as well. I'm not sure we need the two levels of feedback.

I went ahead and made this change. So now:

The plugin is also disabled during the beta/RC period. The reasoning is that the Gutenberg features and new code have already been back ported to Core at that time. And you need to update Gutenberg to the next version in order to include the features that were not back ported (targeted for the next WP version).

It also means that the max version should be updated right before/after beta 1.

It also means that the max version should be updated right before/after beta 1

Yep, as soon as the version with the latest fixes and features for the current WP development version is released (the latest Gutenberg version scheduled to be synced with core trunk).

As far as I see further fixes to merged features are done in minor (dot) releases. There GUTENBERG_MAX_WP_VERSION would be same as in the (older) major release.

youknowriad

LGTM 👍

mtias · 2023-10-26T12:13:39Z

The display is a bit odd since it reads like the plugin is active while it's not loaded. Not a blocker, but we could add something like (not loaded) next to the Deactivate action.

youknowriad · 2023-10-30T07:53:33Z

I tried looking here, I'm not sure there's any filter to that allows us to alter the "name" cell in the plugin table.

azaozz · 2023-10-30T10:35:04Z

Yea the whole concept of having to install plugins and then activate them is a bit ... different that most other places. Showing "(not loaded)" right next to "Deactivate" sounds good imho. Wondering if "(disabled)" would be even clearer?

Alternatively can probably replace the "Deactivate" with "Uninstall", although technically the plugin is still active. Afaik there's no problem uninstalling active plugins (all "must use" plugins are like that). Will do a bit of testing.

azaozz · 2023-10-30T14:57:32Z

Added "(disabled)" to the plugin actions links.

youknowriad · 2023-10-31T08:14:39Z

Looks like there's some failing e2e tests preventing the merge of this PR.

azaozz · 2023-11-07T12:33:41Z

some failing e2e tests...

Not sure if they are related, or rather cannot figure out what's actually failing. Seems the only possible thing that might fail is when the WP version during the tests is either missing or incorrect/not supported. Cannot see where that is set though.

- Add couple more warnings when Gutenberg is too old or too new for the WP installation. - Add warnings in the plugins list table row.

Co-authored-by: Nikhil <Nikschavan@users.noreply.github.com>

Rename GUTENBERG_NEXT_UNSUPPORTED_WP_VERSION to GUTENBERG_MAX_WP_VERSION, etc.

Also tweak the warnings messages a little and simplify the version compare for newer WP versions.

update `@since` to 17.0.0.

Check if e2e tests are failing because of using too new WP version.

azaozz · 2023-11-23T22:50:09Z

Rebased in an attempt to fix the e2e tests. The timeouts were fixed however "No node found for selector" popped up.

azaozz · 2023-11-24T21:13:55Z

Seems the e2e tests fail because they are run in an alpha (core trunk) build of WordPress. Tested by increasing GUTENBERG_MAX_WP_VERSION to allow the latest dev WP version, and the e2e tests passed.

Just to confirm: the intention here is to auto-disable (not load) the Gutenberg plugin when it is run in a version of WordPress newer than the "Tested up to" version from the plugin's readme, right? In that case why are the e2e tests being run in a newer version of WP, the current development version? Seems they should be run in the currently released WP version?

tellthemachines · 2023-11-26T22:40:11Z

why are the e2e tests being run in a newer version of WP, the current development version?

Good question 😄
I think it's to make sure that no new plugin features conflict with new core features, and testing ahead of time that Gutenberg works with the next WP version.

Also update some docs.

azaozz · 2023-11-29T00:26:41Z

to make sure that no new plugin features conflict with new core features,

Yea, that's "the other side of the coin". Generally Gutenberg should not be loaded when it will be "downgrading" code that has already been added to core. This may happen more often in the future as "the push" is to move/sync code from Gutenberg to core as soon as possible, while WP is still in alpha.

and testing ahead of time that Gutenberg works with the next WP version

That may not be necessary any more as the current Gutenberg version will not be loaded in the next (released) WP version. Using the GUTENBERG_MAX_WP_VERSION will prevent it.

In any case, changed it back to still load the plugin in the next WP version while it is in development. For example: If GUTENBERG_MAX_WP_VERSION is 6.4, the plugin will load in 6.5 alpha, beta, and RC, but not in the released 6.5.0. That will prevent fatals and other errors in production while still allowing more flexibility for testing.

tellthemachines · 2023-11-29T06:31:54Z

Generally Gutenberg should not be loaded when it will be "downgrading" code that has already been added to core.

Yeah this is an interesting problem 😄 but given the speed of development in Gutenberg vs core there would only actually be a downgrade if an older version of the plugin were being used. The e2e assume that Gutenberg trunk will always be ahead of core, which I think is correct: trunk should never be behind core. But we also run e2e on release branches when preparing patches for older WP versions, so whatever we go with here should also work in that scenario. I think in the release branches it would make sense to run the tests on whatever WP version they're targeted at.

github-actions · 2024-02-06T18:20:34Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @WPprodigy.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: WPprodigy.

Co-authored-by: azaozz <azaozz@git.wordpress.org>
Co-authored-by: draganescu <andraganescu@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: Nikschavan <nikschavan@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>
Co-authored-by: hellofromtonya <hellofromtonya@git.wordpress.org>
Co-authored-by: mtias <matveb@git.wordpress.org>
Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

hellofromtonya · 2024-02-06T19:33:33Z

gutenberg.php

-gutenberg_pre_init();
+// Minimum supported version. Has to match "Requires at least" header above.
+if ( ! defined( 'GUTENBERG_MIN_WP_VERSION' ) ) {
+	define( 'GUTENBERG_MIN_WP_VERSION', '6.2' );


Is the min version always known for each Gutenberg release?

What if the plan changes and thus that version might be different (maybe older such as a previous minor or later)? Later isn't necessarily problematic as the remedy is to upgrade. Older is problematic in that a fatal error might happen.

Wondering if instead, this minimum version should be set by Core and consumed in the plugin. For example, Core could provide a global function such as _get_plugin_wp_min_compatible_version() where for-core plugins like Gutenberg could invoke. Let Core determine which version is the min compatible.

Uh, sorry but I think I'm missing something? Does that mean we're getting rid of the "Requires at least" plugin header?

What if the plan changes and thus that version might be different

That means a plugin will not "know" what is the minimum WP version it supports at release, and want to change/fix it later? This hasn't been a problem... forever, not sure it is a problem now?

Wondering if instead, this minimum version should be set by Core...
...
Let Core determine which version is the min compatible.

Not sure how core would "know" if a plugin is fully compatible or not. Emphasis on "fully compatible" here as some incompatibilities are not obvious or easy to detect.

Whoops, this isn't correct. Sorry. It's a minimum version in Core, but a max version in the plugin.

Not sure how core would "know" if a plugin is fully compatible or not. Emphasis on "fully compatible" here as some incompatibilities are not obvious or easy to detect.

Historically within Core itself, it views the minimum compatible version of the GB plugin to be the first version that causes a fatal error. That's very different from defining "fully compatible". It's focused on preventing fatal errors for users.

Typically the versions that are compatible with the WordPress version in development aren't known until close to WP Beta 1.

Just before Beta 1 or during beta is when the harded code GB version is updated Core (currently within _upgrade_core_deactivate_incompatible_plugins()).

What's my point?

The plugin's actual maximum WordPress version might not be known at the plugin release time. It might change as the WordPress dev cycle advances into beta.

For example, a fatal error happened recently which then caused an update in Core to set the 17.6 as the minimum compat version for WP 6.5. I'm wondering if 17.5.x or older would have know it's max WP version is WP 6.4, and not 6.5?

How can released GB plugin versions know if Core itself will deactivate it due to be incompatible?

That's where the plugin could use the proposed Core function _get_plugin_wp_min_compatible_version().

Using the previous example, that Core function would return 17.6. So then released plugin versions could invoke the Core function and take action itself. Then in time once all released versions of the plugin have this new code, Core would no longer need to deactivate the plugin, i.e. because the plugin handles it itself.

Whoops, this isn't correct. Sorry. It's a minimum version in Core, but a max version in the plugin.

Ahh I see. I knew I'm missing something :)

How can released GB plugin versions know if Core itself will deactivate it due to be incompatible?

The same way it "knows" it is not going to be installed on a server with a PHP version lower than the minimum required, and in a "too old" WP? I.e. the plugin sets its own requirements, and WP makes sure these requirements are met. Same as PHP and WP versions, and now plugin dependencies.

Similar logic has existed in core since 2007 (WP 2.0) I think: plugins can specify minimal WP version. This is opt-in and enforced by the plugins repo API and by the core plugins API.

Adding another optional requirement for a maximum supported WP version would be best to follow the same logic/design imho, and should be available for all plugins. I know of 2-3 other plugins that can use this right now, for example the Test jQuery Updates plugin that will probably be used again for jQuery 4.0.

That's where the plugin could use the proposed Core function _get_plugin_wp_min_compatible_version().

Hmm, don't think WP (core) would be able to "know better" which plugin is compatible with which version. This info should be in the plugin, and is set to a constant in this PR. So not sure why a plugin will have to use a WP function to get the info it sets itself? Think it is the opposite: WP should "read" what the plugin requirements are and check if they are satisfied. If not satisfied WP should not load the plugin and should warn the users/site admins.

The plugin's actual maximum WordPress version might not be known at the plugin release time. It might change as the WordPress dev cycle advances into beta.

Right. For that reason the "maximum supported" WP version can only be a major (two digits) version and should (generally) match the "tested up to" plugin header.

Minor version of Gutenberg will still support the same "max WP" version. In addition the "max WP" version will include support for the next "WP Trunk", (alpha, beta, RC). This is needed in order to be able to use the current Gutenberg releases in a WP Trunk installs, like on wp.org. Please see the discussion above.

azaozz · 2024-02-06T23:15:32Z

Just FYI, the reason this PR is not yet merged is that the logic (when to not load newer Gutenberg in older WP) is good, but seems the code would be better off in core, as part of the "PHP fatals prevention" there. We've been thinking/working on that with @hellofromtonya for a while and there will most likely be an initial version of this in WP 6.5.

WPprodigy · 2024-02-07T18:56:09Z

I really do think it would be good to have the loader-prevention inside this plugin as well though. It's the only place we can fully prevent a bad outcome.

At the end of the day, plugins can be loaded via a require ... statement in PHP, though often there is more sugar on top of that. This being more common in environments that have the plugins managed in version control and activating them is done through code rather than through the UI.

IMO, the main goal here should be to make WP upgrades as safe as possible. And at the moment, having the Gutenberg plugin on a site poses a very big threat as fatals after a WP upgrade are fairly common (due to class name re-use for example).

I haven't closely followed the other work being done in core, but I can't see this fully be solved without the GB plugin preventing itself from loading if it's unsafe to do so. And as far as development lifecycle goes, the only truly required information (as far as I can reason) would be for a core release to determine it's minimum supported version of GB. Because that's when the breakage is occurring.

The sooner we get the loader-prevention code into the GB plugin the better as well, as we won't get the protections right away as not everybody will be using the latest version of the plugin. So starting that timer as soon as possible would be nice.

azaozz · 2024-02-17T21:12:06Z

I really do think it would be good to have the loader-prevention inside this plugin as well

Well, there's nothing stopping us from adding it in the plugin too, however that would duplicate core's functionality and might eventually interfere with it. The idea here is to add another type of "plugin requirement": maximum WP version. This will be the forth requirement type, the others are: minimum WP version, minimum PHP version, other plugins (as of 6.5).

That way WP will be able to handle these cases in a consistent way which will be easier for the users to follow/understand, and the incompatibility messages/warnings would be a bit better. Also other plugins would be able to set the same requirement.

I can't see this fully be solved without the GB plugin preventing itself from loading

For now the idea is for WP to be more in control when loading plugins. It will need to have the "plugin meta" (the plugin's headers) either easily readable at plugin loading time or caches (in a DB option/persistent cache). Then the plugin will have an "init" function that WP will call if it is safe to initialize the plugin.

This way WP will be able to show all appropriate messages/warnings about incompatible plugins, and prevent loading them when they are updated from FTP or git/svn. Also the warnings can be shown regardless if a plugin is activated or not.

See: https://core.trac.wordpress.org/ticket/60491#comment:13

Nikschavan reviewed Oct 4, 2021

View reviewed changes

gutenberg.php Outdated Show resolved Hide resolved

gutenberg.php Outdated Show resolved Hide resolved

gutenberg.php Outdated Show resolved Hide resolved

stevenlinx added the [Type] Experimental Experimental feature or API. label Oct 29, 2021

noisysocks added Gutenberg Plugin Issues or PRs related to Gutenberg Plugin management related efforts and removed [Type] Experimental Experimental feature or API. labels Nov 10, 2021

hellofromtonya self-requested a review November 10, 2021 13:41

t-hamano mentioned this pull request Aug 31, 2023

Gutenberg Plugin: Use plugin header to varidate WP/PHP version requirements #54090

Open

gziolo reviewed Oct 10, 2023

View reviewed changes

gziolo reviewed Oct 13, 2023

View reviewed changes

gziolo added the [Type] Enhancement A suggestion for improvement. label Oct 13, 2023

gziolo changed the title ~~Add requirement for minimum and maximum WordPress versions~~ Plugin: Add requirement for minimum and maximum WordPress versions Oct 13, 2023

gziolo requested review from priethor, annezazu, tellthemachines and ockham October 13, 2023 08:45

youknowriad reviewed Oct 26, 2023

View reviewed changes

gutenberg.php Show resolved Hide resolved

youknowriad reviewed Oct 26, 2023

View reviewed changes

youknowriad approved these changes Oct 26, 2023

View reviewed changes

azaozz added 2 commits November 23, 2023 13:18

Add min and max WP version constants

6222b71

- Add couple more warnings when Gutenberg is too old or too new for the WP installation. - Add warnings in the plugins list table row.

Fix docblocks for filter callbacks.

c5205ae

azaozz and others added 12 commits November 23, 2023 13:18

Fix docs string order.

a2c4cf0

Update gutenberg.php

4697e9e

Co-authored-by: Nikhil <Nikschavan@users.noreply.github.com>

Update gutenberg.php

0f824b7

Co-authored-by: Nikhil <Nikschavan@users.noreply.github.com>

Update gutenberg.php

c976fb6

Co-authored-by: Nikhil <Nikschavan@users.noreply.github.com>

Update to current versions

fcc78ae

More cleanup and updates

2748c42

Rename GUTENBERG_NEXT_UNSUPPORTED_WP_VERSION to GUTENBERG_MAX_WP_VERSION, etc.

Fix typo

ef09cbc

Only show the warnings on the Dashboard and the Plugins screen.

b475a7d

Disable Gutenberg during the beta period as well

1927d21

Add/fix the explanations on how to set GUTENBERG_MAX_WP_VERSION.

09519e2

Also tweak the warnings messages a little and simplify the version compare for newer WP versions.

Add disabled action links notice,

ae895f6

update `@since` to 17.0.0.

Move (disabled) before Deactivate.

ddc4ce3

azaozz force-pushed the fix/maximum-supported-wp-version branch from 27f1cdf to ddc4ce3 Compare November 23, 2023 21:22

Update the since for 17.2.0, add some more inline comments.

773ba28

Check if e2e tests are failing because of using too new WP version.

azaozz mentioned this pull request Nov 24, 2023

What version of WordPress should the e2e tests be using: latest release or the current development (alpha)? #56521

Open

Update: do not disable the plugin in the next development version of WP.

61c973e

Also update some docs.

Merge branch 'trunk' into fix/maximum-supported-wp-version

187366a

hellofromtonya reviewed Feb 6, 2024

View reviewed changes

	if (
	! $plugin_version &&
	preg_match( '@^\s\\sVersion:\s([0-9.]+)@', $line, $matches )
	) {
	$plugin_version = $matches[1];
	}

Plugin: Add requirement for minimum and maximum WordPress versions #35194

Are you sure you want to change the base?

Plugin: Add requirement for minimum and maximum WordPress versions #35194

Conversation

azaozz commented Sep 28, 2021 • edited Loading

Description

Checklist:

Nikschavan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azaozz Oct 12, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azaozz Oct 13, 2023 • edited Loading

Choose a reason for hiding this comment

gziolo commented Oct 10, 2023

github-actions bot commented Oct 12, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azaozz commented Oct 13, 2023

WPprodigy commented Oct 25, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azaozz Oct 30, 2023 • edited Loading

Choose a reason for hiding this comment

youknowriad left a comment

Choose a reason for hiding this comment

mtias commented Oct 26, 2023

youknowriad commented Oct 30, 2023

azaozz commented Oct 30, 2023 • edited Loading

azaozz commented Oct 30, 2023 • edited Loading

youknowriad commented Oct 31, 2023

azaozz commented Nov 7, 2023

azaozz commented Nov 23, 2023

azaozz commented Nov 24, 2023 • edited Loading

tellthemachines commented Nov 26, 2023

azaozz commented Nov 29, 2023 • edited Loading

tellthemachines commented Nov 29, 2023

github-actions bot commented Feb 6, 2024 • edited Loading

Unlinked Accounts

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azaozz Feb 17, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azaozz commented Feb 6, 2024

WPprodigy commented Feb 7, 2024

azaozz commented Feb 17, 2024 • edited Loading

azaozz commented Sep 28, 2021 •

edited

Loading

azaozz Oct 12, 2023 •

edited

Loading

azaozz Oct 13, 2023 •

edited

Loading

github-actions bot commented Oct 12, 2023 •

edited

Loading

azaozz Oct 30, 2023 •

edited

Loading

azaozz commented Oct 30, 2023 •

edited

Loading

azaozz commented Oct 30, 2023 •

edited

Loading

azaozz commented Nov 24, 2023 •

edited

Loading

azaozz commented Nov 29, 2023 •

edited

Loading

github-actions bot commented Feb 6, 2024 •

edited

Loading

azaozz Feb 17, 2024 •

edited

Loading

azaozz commented Feb 17, 2024 •

edited

Loading