feat: add rippled API v2 support and use as default

khancode commented 4 months ago

High Level Overview of Change

Add rippled api_version support for v2 and use as default while maintaining support for v1.

Context of Change

rippled api_version 2 is supported by 100% of rippled servers now that numerous v2 amendments have activated. (as of April 8, 2024.). Therefore, we should default to using v2 and maintain support of v1 response types.
This feature will be released as a major bump version since it's a significant breaking change.

Type of Change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Refactor (non-breaking change that only restructures code)
[x] Tests (You added tests for code that already exists, or your new feature included in this PR)
[ ] Documentation Updates
[ ] Release

Did you update HISTORY.md?

[x] Yes
[ ] No, this change does not impact library users

Test Plan

Updated existing unit/integ tests and added new ones.

khancode commented 2 months ago

api_version 2 is supported by 100% of rippled servers now that numerous v2 amendments have activated. (as of April 8, 2024.) Therefore, we decided to drop type support for API v1 and just default to use v2 - https://github.com/XRPLF/xrpl.js/pull/2687

khancode commented 2 months ago

Reopening since we decided it's best to continue TS type support of v1 and only deprecate features/versions when rippled does.

khancode commented 1 week ago

[ ] For all your tests, shouldn't we be keeping v1 tests? I know you added some v1 tests, but you changed a lot of tests to use tx_json but I didn't see tests for making sure v1 still works

[ ] I think we should add a warning to people when they're trying to access v1 data but the library is defaulting to v2 -- Likely we can use a class getter than throws an error when they try to access the wrong tx or tx_json

I only kept v1 tests specifically for the RPC responses that changed. I thought it would be repetitive to test for v1 in all other tests that indirectly use these RPC responses. So the v1 response tests are still covered.
I don't think we shouldn't add this complexity since that's what the updated/different TS models are for and virtually all validators run v2 now.

XRPLF / xrpl.js