Repository navigation
[Feat]: A2A v0.3.0 and v1.0.0 Coexistence #762
Description
Activity
Hi @sduskis thank you for flagging this. We made a conscious decision in the run-up to 1.0 to not support 0.3.0 of the spec.
However, we realise now that this might have been the wrong decision. Also, as the spec evolves beyond 1.0 we will need to support multiple protocols anyway. So we will look into this, and use this issue to discuss between ourselves.
It might not make it in time for our 1.0 release, but we think we can include it in a later 1.0.x release.hey @kabir ,
Have there been any more thoughts about this? We are in the process of working out how we will support the migration from 0.3 to 1.0.Also, are there any ETAs on when there will be a stable 1.0 release?
Cheers- changed the title
[-][Feat]: A2A v0.3.0 and v1.0.0 Coexistance[/-][+][Feat]: A2A v0.3.0 and v1.0.0 Coexistence[/+]on Apr 9, 2026 Hi, we just had a long meeting about this this morning, and will work on this next :-)
I'm currently looking at #757 which is a big breaking change, but think we can release a beta once this works.
Then we have a few TCK issues to sort out, but hopefully the 1.0 final release isn't too far awayReacted by cammckenzie-atlassian@cammckenzie-atlassian @sduskis FYI we have started working on this, and the WIP is in https://github.com/a2aproject/a2a-java/pulls.
We've almost got the 0.3 TCK working against a server provisioned with the 0.3 protocol.
Next step will be to look into what we need to do to be able to use both protocols at the same time.Amazing, thanks @kabir
Great, thanks for the updates @kabir
@kabir I have just had a chance to look at this. My hope was that the conversion of types etc. was going to be handled by the compatibility layer, but unless I'm misinterpreting it seems like we would need to explicitly use a different client when communicating with a legacy server (0.3) and deal with all the 0.3 types in the code?
This means essentially we have to duplicate any interactions with the A2A client (or write our own wrapper that maps 0.3 types into 1.0 types) until we can be sure that all of the servers we communicate with have moved to 1.0.
Am I missing something?
CheersHi, yes that is the way it works at the moment.
I can see from what you say that this might be a bit tricky from a user perspective now that you mention it.
One rough idea is that perhaps an option could be to create a compatibility mode for the main client, so that it delegates to the 0.3 client?
Then it could do similar conversion to how we do it on the server between the 0.3 and 1.0 types.
However, some of the methods changed names between the protocol versions, and names of things in the nested parameters and return types might have changed too. But since we're able to do this in the server conversion layer, that might not be an issue.
But there are some big proposed changes in the spec which I haven't digested yet, but might cause some problems going forward for this approach.
I haven't looked deeply at this, and won't be able to for a while.
If you have time to look/propose something, we'd be happy to provide guidance/review :-)
@cammckenzie-atlassian Please see #1151. It isn't totally finished yet, but I hope it will be later this week.
Is your feature request related to a problem? Please describe.
My ecosystem has a bunch of agents talking A2A, primarily 0.3.0. I'd like to evolve the ecosystem to export services for 0.3.0 and 1.0.0. Is there a plan to support both in the same library?
Describe the solution you'd like
It would be useful to have APIs that convert between 0.3.0 and 1.0.0. I believe that most systems would start exposing 1.0.0 as a proxy for 0.3.0 and then migrate their implementation to be 1.0.0 compliant with a proxy that serves 0.3.0.
Describe alternatives you've considered
No response
Additional context
No response
Code of Conduct