Repository navigation
Roadmap to WP 6.9: defining and deciding #83
Description
Activity
WP 6.2 Beta: https://github.com/WordPress/abilities-api/milestone/2
Later: Anything after 6.2 but considered a priorty https://github.com/WordPress/abilities-api/milestone/4Guessing you mean 6.9 here? :) Thanks for putting this together.
Reacted by Greg Ziółkowski, Tammie Lister and Jeffrey PaulReacted by Tammie ListerI updated the references from WP 6.2 to 6.9 😄
Reacted by Tammie Lister and Jeffrey PaulReacted by Tammie ListerThank you for updating that (facepalm), apologies for shorthand also on just using 6.9 that shouldn’t be case. I absolutely did. I caught a few more so think I have got the majority of them all in things.
@gziolo thank you so much for sub-issues.
- changed the title
[-]Roadmap to 6.9: defining and deciding[/-][+]Roadmap to WP 6.9: defining and deciding[/+]on Sep 23, 2025 There are two outstanding decisions need discussion within the comments in order to ensure we have a full roadmap within milestones. They are:
Client side capabilities. This has a PR: #60.
Are we still on the fence on if it is being included? I personally would love to see client side abilities in 6.9. I think client abilities are an important addition and they open up a lot of different opportunities (navigation, working with the block editor, the command palette, etc). It seems like this is the general sentiment.
What exactly is left outstanding to decide about its inclusion and how can I help push this over the finish line for 6.9?
I think the main open question is if we should continue working via this repository or move to the Gutenberg repo right way. I don't feel strongly since I believe we can publish from either place. I'm leaning towards working in this repository alongside the server side implementation until a later point.
Client-side capabilities should be included. What do we need to do to make that happen?
@gziolo, I know you were reviewing the actual mechanism to get it into core? Is that the main thing that we are still reviewing at this point?
@Jameswlepage, at this point, I believe that @emdashcodes addressed all the feedback from reviewers for the client-side registry implementation. We need a confirmation that everything looks good, and perform a final round of testing (on my to-do list for the week), and we should be all set for the repository. One thing I'm not sure about is whether the mechanism to include JS assets in the Composer package is in place or whether we need to seek some alternative solution like cutting a release branch, building assets there, and using them for a new release. That would be needed so we can test with projects that consume the Composer package.
Seperately, we need to agree on the path for inclusion in WordPress core. There are two possibilities based on my assessments:
- Move the local npm package to Gutenberg and publish to npm automatically with the regular workflows there.
- Publish to npm directly from the existing location, which most likely would be handled manually from a local machine by someone with npm access to the WordPress organization (I can take care of it initially).
In both cases, WordPress core would consume the JS code in the same fashion as all other WordPress packages.
Ok so what I am seeing in this issue so far is at least a decision that client side will be included - woohoo one decision down! I updated the issue to note that.
The ‘what’ to include still needs deciding unless I am not seeing that somewhere.
The ‘what’ to include still needs deciding unless I am not seeing that somewhere.
What core abilities to include – it's still not clear what abilities should be included in WordPress core in 6.9, together with the API. It isn't strictly mandatory, but it would be great to make some decisions this week so we have time to act accordingly. During last week's sync meeting, we talked mostly about:
At the same time, on the practical level, it would be much simpler to start small and include abilities like:
- get site info
- get user info
Copying this over from Slack, but I am not massively opposed to starting simple.
Because there's no consumer facing feature I don't think we dramatically limit what will be built with the API. For me in 6. 9 the main goal was to get the API in. Being mindful with the first abilities that get included is probably good, and allows us to be nimble. It would be difficult to depreciate a ton in the future.
At the same time, I still do think there's a balance to strike where Core abilities should be able to be formed into an impressive experience out of the box.
There have been ongoing discussions about layered abilities, tools that bundle many into one, an atomic versus layered approach, etc.
My current thinking is that the atomic approach is best. Many abilities can always be combined into more aggregate ones, but it's harder to split bigger abilities out into smaller pieces. Also, because this is an API that can be used for more than just agents, I like starting small and building up.
10 remaining items
@JasonTheAdams, excellent! Thank you for the clarification. @galatanovidiu followed up with an issue and PR:
Let's continue that topic there.
Reacted by Jason AdamsA way to control whether an ability gets exposed in the REST API is ready for review (defaults to
falselike other concepts that supportshow_in_rest):- added a sub-issue
on Oct 8, 2025 - removed a sub-issue
on Oct 8, 2025 - removed a sub-issue
on Oct 13, 2025 I think this can be closed now it’s put into the issues and various places. If that’s wrong we can always reopen.
Reacted by Jeffrey PaulReacted by Greg Ziółkowski
This issue is meant to lead to the creation of a roadmap and clarification of the existing milestones.
Current milestones
There are 3 milestones so far and one is due the end of the month:
The roadmap to WP 6.9
Initially the roadmap is going to be heavily focused on 6.9, there can is a ‘later’ milestone though to use for anything outside.
Triage and ensuring issues made
Whilst making sure the decisions are made, it’s a good time now to make sure everything to be decided for 6.9 has an issue and also if it doesn’t one is created. Along with this let’s review the milestones to be really sure what we have in them.
Proposal to release to schedule
In order to make this easier for us to manage, I would propose that we have a two-week release cycle going up and during 6.9 or consider if we should release. If there are things to, we ship. This means we can rapidly bug fix in testing, it also means we can set some nice timed milestones and cadence for everyone.
Once WP 6.9 is locked in, we can stop this cadence or review if it indeed is working for everyone.
———————————
Decisions needed
There are two outstanding decisions need discussion within the comments in order to ensure we have a full roadmap within milestones. They are:
Once those decisions are made they can be added to the milestones and issues updated if applicable.
Next steps
Pinging a few people for input and then after this should have decisions by mid-week, to move to locking in milestones and focusing on shipping. Anyone is welcome to add input, but particularly pinging anyone that participated in the discussion during weekly sync.
@Jameswlepage @felixarntz @jeffpaul @swissspidy @gziolo @justlevine @galatanovidiu