Hi all, I would like to propose consolidating the current node-casbin extensions into a single monorepo, together with a unified ASF-compliant release process. Motivation
The current ecosystem of node-casbin extensions (e.g., adapters for Redis, MongoDB, MySQL, etc.) is distributed across multiple independent repositories. This setup introduces several challenges: - Fragmented maintenance Each repository requires separate CI/CD, issue tracking, and release management, which increases operational overhead. - Inconsistent release process Different extensions may follow different release practices, making it harder to align with ASF’s source-based, vote-driven release model. - Lack of unified governance It is difficult to enforce consistent standards such as license headers, code style, and testing across repositories. - Inefficient ASF release workflow Since ASF requires a vote per release, releasing each extension independently significantly increases the overhead. Goals This proposal aims to: - Unify all node-casbin extensions into a single repository to improve maintainability and contributor experience - Support independent versioning for each extension so that components can evolve at their own pace - Establish a single ASF-compliant release process with one vote per release cycle - Standardize development and release workflows across all extensions Non-Goals - Enforcing a unified version across all extensions - Introducing tight coupling between extensions - Changing the runtime behavior or APIs of existing packages Proposed ApproachRepository Structure We will adopt a monorepo layout: node-casbin-extensions/ ├── packages/ │ ├── node-casbin-redis/ │ ├── node-casbin-mongo/ │ ├── node-casbin-mysql/ │ └── ... ├── package.json ├── pnpm-workspace.yaml └── .changeset/ Each extension remains logically independent. Workspace Management We will use pnpm workspace to: - Manage all packages in a single repository - Enable batch operations (build, test, lint) - Simplify dependency management Versioning Strategy We will adopt independent versioning per package using Changesets: - Each extension maintains its own semantic version - Only changed packages are version-bumped and published - Changelogs are generated automatically Example: - [email protected] - [email protected] Release Model (ASF-Aligned) We adopt a single release snapshot model: - A release corresponds to a repository-wide snapshot - A single Git tag represents the release, for example: node-casbin-extensions-0.3.0 - The release includes multiple packages with their respective versions Release Process 1. Prepare release - Run build and tests across all packages - Use Changesets to finalize versions and changelogs 2. Create release candidate (RC) - Tag the repository (e.g., node-casbin-extensions-0.3.0-rc1) - Generate source tarball with LICENSE/NOTICE 3. ASF vote - Send a [VOTE] email including artifact links and verification steps 4. Finalize release - Promote RC to final tag - Publish updated packages to npm GitHub Release Strategy GitHub Releases will mirror ASF releases (not the source of truth), and include: - List of updated packages and versions - Changelog summary - Links to ASF-hosted artifacts Tooling - pnpm workspace for monorepo management - Changesets for versioning and release orchestration - GitHub Actions (optional) for CI and release automation Benefits - Reduced release overhead with one ASF vote per cycle - Improved maintainability via centralized tooling and governance - Flexible evolution with independent versioning - Better contributor experience with a unified workflow - Clear ASF compliance with well-defined release boundaries Feedback is very welcome. Thanks, Zixuan
