[wp-trac] [WordPress Trac] #64345: Ability names should support versioning

[WordPress Trac]

#64345: Ability names should support versioning
--------------------------------------+------------------------------
 Reporter:  jason_the_adams           |       Owner:  (none)
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  AI                        |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------------

Comment (by artpi):

 I am honestly conflicted about this.
 I can empathize with @justlevine tring to keep things simple, but i also
 think there is a route where we will need just oldshchool versions.

 We have 3 concerns here.

 ** 1: When abilities are called in a single shot**

 When you call the ability in a single shot - like in MCP, in a programatic
 way. Single shot means that the ability is both discovered and executed in
 the same session.

 - Don't care about the versions
 - You want to use the newest version of the ability
 - You don't want to deal with versions in the ability id

 ** 2: When Marketing your ability**

 - You want a recognizeable name for your ability so you can promote it in
 the ecosystem
 - You don't want the version in the id


 ** 3: When dependening on an ability**

 Let's say plugin B is using an ability provieded by plugin A:
 You very often want to be able to pin an ability version that behaves in a
 predictable way.

 - If you are writing system prompt instructing the LLM to use the ability
 in a certain way or give it instructions to behave in a certain way
 - You are using ability in a larger workflow where output of one ability
 flows to the other and you depend on it the shape of input/output.


 So really the ideal system would:

 - Keep ids stable
 - Introduce an option to run a legacy ability if provided.

 ----------



 As such, commenting on @jorgefilipecosta comment:

 > Sharing here for discussion an alternative approach following the same
 pattern we use for blocks in Gutenberg, which has been working for many
 years.

 I like the idea of trying to have different apis behave in the same way.

 So in that scenario:

 - plugin B is using an ability X provieded by plugin A:
 - Developer of plugin A is introducing new behaviour of Ability X.
 - They also attach the old behaviour so that when it is detected, legacy
 callback gets called instead of default one?


 The core difference between abilities and blocks is that the abilities can
 haev a long dependency chain with cascading failures while the blocks when
 they fail, they fail locally and the worst that can happen is visual
 problems.

 Lets imagine abilities used for core financial operations: Handling floats
 in financial operations is something we had to learn the hard way multiple
 times in WooCommerce:

 - Old: SUM = ( float a + float b ).toString() + "$"
 - New: SUM = ( ( float a * 100 + float b * 100 ) / 100  ).toString() + "$"

 If you don't believe me, try it yourself:




 {{{
 const a = 0.1, b = 0.2;

 const oldSum = (a + b).toString() + "$";
 const newSum = (((a * 100) + (b * 100)) / 100).toString() + "$";

 console.log(oldSum); // "0.30000000000000004$"
 console.log(newSum); // "0.3$"
 }}}


 Now developer of plugin B has accounted for the old behaviour in their
 logic, but now developer A introduces this new behaviour and suddenly
 financial math is off. There was no schema changes, and yet everything
 changed.


 I still think the ability to introduce a breaking change will be needed,
 and clever duck typing is not going to solve this problem.


 It really sounds like a good fit for an additional `version` field:
 - Keeps ids stable
 - Developer can choose to provide version or not
 - They can choose to bump it if behaviour is breaking
 - When they do, they have to ship all the previous versions too.
 - The developer depending on an ability can choose to pin a version they
 depend on


 {{{
 wp_get_ability( 'artpi/sum', 1 );
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64345#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform