Are there any plans for supporting the updated API version?
From the code, I don’t see why this client wouldn’t work with the changes from the latest version aside from the constant version number in the client class.
I propose that, like the official Node and Python libraries, this library accepts a fifth parameter in the constructor of the Plaid class that defaults to the current supported version.
This solution makes the most sense because this library isn’t strongly typed and it needn’t be.
Upon review of the change log it appears that the request endpoints haven’t ever changed, only response schemas.
That being said I can understand why the versioning approach that the Java/Ruby libraries implement could come in handy in the future. Supporting this strategy via composer is simple and supported.
I am willing to make either change with consensus from maintainers. International support is important to my project.
Hi,
Are there any plans for supporting the updated API version?
From the code, I don’t see why this client wouldn’t work with the changes from the latest version aside from the constant version number in the client class.
I propose that, like the official Node and Python libraries, this library accepts a fifth parameter in the constructor of the
Plaidclass that defaults to the current supported version.This solution makes the most sense because this library isn’t strongly typed and it needn’t be.
Upon review of the change log it appears that the request endpoints haven’t ever changed, only response schemas.
That being said I can understand why the versioning approach that the Java/Ruby libraries implement could come in handy in the future. Supporting this strategy via composer is simple and supported.
I am willing to make either change with consensus from maintainers. International support is important to my project.