Proposal: Path to v3.0

[nkramer44]

We are currently working on improving the key management and signing functionality in xrpl4j, as well as contemplating a reorganization of our modules so that developers only have to import xrpl4j-core.

As discussed in #182, we would rather not rush to a version 3 and break existing functionality without providing a clear and well documented upgrade path from v2.x to v3.0. So, @sappenin and I propose the following sequence of work:

• Get v3-dev-preview to a nearly complete state (See Things to fix in XRPL4j-v3-dev-preview #170).
• Create a v2.next branch off of main
• Iteratively commit v3-dev-preview branch enhancements into v2.next branch (keeping PRs small for future readability), keeping (and deprecating) old code so as not to break anything
• Once we are happy with the v2.next branch, merge into main (no squash) and release a v2.x
• Document v2.x new functionality
• Create a v2 maintenance branch for potential bug fixes in v2
• Begin considering main as the v3 branch (any releases from main will be v3.x)
• Implement module changes suggested in Refactor project modules to improve developer experience #185 in the main branch
• Document v3.0.0 functionality (ie pom.xml changes for new module structure)
• Delete all deprecated code
• Release v3.0.0

[sappenin]

Closing this discussion now that v3 of xrpl4j is released.