Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modularization of CDT for Enhanced Developer Flexibility #278

Open
bhazzard opened this issue Nov 30, 2023 · 0 comments
Open

Modularization of CDT for Enhanced Developer Flexibility #278

bhazzard opened this issue Nov 30, 2023 · 0 comments
Assignees

Comments

@bhazzard
Copy link
Collaborator

User Story:
As a blockchain developer, I want to have the ability to selectively integrate specific libraries with the features I need to develop my smart contracts, so that I can avoid upgrading for features I don't need.

Problem:
Currently, the developer experience with the Contract Development Toolkit (CDT) requires updating to the latest version whenever new features are released. This is not always necessary or desired, as many developers may not require the newly added features. This process places undue pressure on all developers to upgrade, even when it's irrelevant to their needs.

Proposal:
We should evolve from the current "kitchen sink" CDT to a more modular system. We can do this by creating smaller, independent libraries for specific functionalities.

Examples of candidates for libraries:

  • BLS
  • BN256
  • Multi Index Tables
  • Serialization
  • Crypto

Benefits:
These libraries would be separate from the main CDT release and would update independently, allowing developers to pick and choose what they need and ensuring compatibility across multiple versions of CDT.

Requirements:

  1. Modular: Develop independent libraries for specific functionalities that are currently bundled in CDT.
  2. Compatible: Ensure that these libraries are compatible with CDT.
  3. Decoupled: Ensure that these CDT upgrades don't require upgrading Library versions and vice versa.
  4. Release Cadence: Establish a distinct release schedule for these libraries, independent of the CDT release cycle.
  5. Documentation: Update documentation so developers know which libraries to use, where to get them, and how to use them.

Acceptance Criteria:

  1. Selective Integration: Developers should be able to integrate only the libraries they need for their project.
  2. Backward Compatibility: The new libraries must be compatible with at least the previous two major releases of CDT.
  3. Independent Functionality: Each library should function independently without requiring a full CDT upgrade.
  4. Documentation Clarity: The documentation should clearly explain how to integrate and use each library.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants