New Signing Functionality in v2?

[sappenin]

There is currently an effort underway to improve and augment the APIs for signing in this library. This work is slated to be released in a V3 of xrpl4j because the improvements introduce a variety of breaking changes (this work currently lives in the v3-dev-preview branch).

Because these changes introduce some new primitives and interfaces, a variety of v2 classes have been marked as deprecated in the v3-dev-preview branch (because we wanted to leave room for a v2 backport release).

The question is: do we even need a v2.x backport release that includes both the new v3 code in addition to deprecating classes that will be removed in v3?

I don't have a very strong opinion either way, but lean slightly towards "don't introduce new v3 code in any v2 release", but wanted to gauge other opinions.

[theotherian]

If we had an enormous user base then yeah, sure, we should backport. As things currently stand I hardly think the benefits justify the effort.

[nhartner]

If there's clear and straightforward path to migrate from v2 to v3, then maybe it's ok to have breaking changes. The last time breaking changes where done, it was not well documented nor straight forward how to migrate. Even with my history with the project, I found myself very frustrated trying to migrate.

[nkramer44]

Just to clarify, are you fundamentally against making breaking changes without some intermediate release with a bunch of things deprecated, or is your main concern around documentation?

There is a world where we deprecate large parts of the library in a 2.x release and then remove that deprecated code in v3, but with the changes we're planning (uber module, new signing service etc), that 2.x release would probably deprecate about 70% of the codebase. Arguably, that's probably what we should do, but considering our small user base, I'm not sure it's worth the extra effort of making sure everything is backwards compatible.

I guess my question is -- would going straight to v3 still give you heartburn if we documented the upgrade process really well?

[nkramer44]

@sappenin and I have been discussing options for releasing new functionality without making breaking changes and providing a clear upgrade path. See #187