Developer Guide

Developer Guide#

Participate in EvoFabric#

Thank you for your interest in the EvoFabric project! Our community is open to everyone, and we welcome you to submit suggestions in various forms or publish your functional components. You can participate through the following methods:

  • Find and report issues or bugs.

  • Propose a requirement or add a new feature.

  • Propose a requirement or add a new component.

License#

The license used in the current project is MIT License.

Development Process#

If you expect to contribute your components or features to EvoFabric, we expect you to follow the following development principles:

  • Clearly describe the components or features you are providing in the PR

  • Ensure that newly added components inherit the existing base class or the factory base class BaseComponent, and that the components can be serialized and deserialized by pydantic.

  • Code follows PEP 8 style

  • Provide unit tests that can run offline to fully verify your functionality

We will organize regular reviews of all new PRs and promptly communicate the progress to you.

Version Strategy#

This project follows a clear versioning strategy to ensure a standardized development process, clear version management, and ease of use and contribution for the community. The versioning system is divided into three categories: mainline versions, release versions, and development versions.

Version Number Naming Rules#

Version numbers use a three-part naming convention:

Major.Minor.Patch[-Suffix]

  • Major Version (MAJOR): The major version number is incremented when incompatible API changes occur.

  • Minor Version (MINOR): Increment the minor version number when adding new features in a backward-compatible manner.

  • Patch Number (PATCH): Incremented when the project makes backward-compatible bug fixes.

  • Suffix (Optional): Used to mark development versions or pre-release versions, for example -rc1, -rc2, -beta.

Version Type Definition#

  1. Mainline Version (Mainline Version)

    • Description: The project’s core development branch containing the latest features and improvements.

    • Naming: Generally no suffix, e.g., 1.2.0.

    • Features:

      • Maintain compatibility with the main version.

      • Can be merged into the release version branch for formal release.

  2. Release Version (Release Version)

    • Description: A thoroughly tested, stable, and usable version released to users.

    • Naming: Follow the version number rules, without a development suffix, for example 1.2.0.

    • Release cycle: Bi-monthly.

    • Features:

      • Does not include unstable features.

      • For production environment and community release.

      • Each version release should record the changelog (CHANGELOG).

  3. Development Version (Development Version)

    • Description: Version for daily development and testing, may contain unstable or experimental features.

    • Naming: Add the -dev suffix after the revision number, for example 1.3.0-dev.

    • Features:

      • Frequent updates, for developers to test and preview.

      • Not recommended for direct use in production environment.

Subsequent Version Plan#

We plan to gradually roll out the following features in subsequent updates:

  • EvoFabric’s frontend UI supports displaying message logs during runtime (including streaming messages), graph structure, and node status, as well as debugging features in the visual interface.

  • Agent Scenario’s Memory Feature

  • Magentic-one and other Multi-agent modules

  • Client, tools, and other resource usage monitoring

Contents