Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release Plugin #189

Merged
merged 1 commit into from
Feb 28, 2024
Merged

Release Plugin #189

merged 1 commit into from
Feb 28, 2024

Conversation

github-actions[bot]
Copy link
Contributor

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@wpengine/wp-graphql-content-blocks@3.1.0

Minor Changes

  • 9fab724: Added support for automatic updates hosted from WP Engine infrastructure. Includes warnings when major versions with potential breaking changes are released.

@github-actions github-actions bot requested a review from a team as a code owner February 21, 2024 18:13
@github-actions github-actions bot force-pushed the changeset-release/main branch 2 times, most recently from 2f606b3 to 6333494 Compare February 22, 2024 22:04
@blakewilson blakewilson merged commit 1802da7 into main Feb 28, 2024
@blakewilson blakewilson deleted the changeset-release/main branch February 28, 2024 16:23
@justlevine
Copy link
Contributor

Is there a way to do this without introducing 3 non-namespaced, production dependencies? This makes me really nervous considering how prominent Composer is in the enterprise space 😬

@mindctrl
Copy link
Contributor

@justlevine we've already released this. I wish I'd seen this earlier, but the PR was open for weeks. The updater code is namespaced. Are you referring to something else?

@justlevine
Copy link
Contributor

justlevine commented Feb 28, 2024

Sorry GH only pinged me about the approval... must have missed the earlier notifications.

My concern is that now in addition to needing to worry about conflicts from a imangazaliev/didom we also need to watch for other plugins using phlak/semver.

And if there's plans for further adoption of blakewilson/wp-enforce-semver as a dep (originally I thought it was proof of design or a mu-plugin), then all those plugins using it are going to be version locking each other too, and will need to be updated together.

If we really need production Composer dependencies (to handle SemVer or anything else), then we should at least use a library like Strauss or phpscoper to prevent conflicts - doubly so when the deps are generic utilities / intended to be used by multiple coexisting plugins.

@justlevine
Copy link
Contributor

No need to act on this now.

My March goal is to commit a dep-free semver + extension version compatibility checker into core, which extensions will be able to tap into uniformly. Once that's in, I'll open an issue/PR.. doubt these deps will release a breaking change before then.

@mindctrl
Copy link
Contributor

@justlevine I see. Thanks for explaining. Honestly I'd like to see this plugin folded into WPGraphQL core, or at least managed by that team. It would simplify almost everything related to maintaining this plugin. I look forward to seeing what you put together in March!

@justlevine
Copy link
Contributor

Honestly I'd like to see this plugin folded into WPGraphQL core, or at least managed by that team. It would simplify almost everything related to maintaining this plugin.

Long term that is indeed the goal (wp-graphql/wp-graphql#1764). Assumingly with the Block Bindings API getting merged in WP 6.5, there shouldn't be any more major blockers 🤞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants