agentscope-ai / agentscope-ai/agentscope-spark-design
Request: Publish GitHub Releases/ Tags for @agentscope-ai/design and @agentscope-ai/chat to support enterprise compliance
- Dominant language
- TypeScript
- Stars
- 448
- Forks
- 36
- PR merge metrics
- No merged PRs in 30d
Description
## Background
We are an enterprise team integrating `@agentscope-ai/design` (v1.0.23)
and `@agentscope-ai/chat` (v1.1.45) into our internal AI Agent platform.
Our company's open-source compliance policy **requires all third-party
dependencies to be referenced from GitHub Releases (tagged commits)**,
rather than npm published versions.
Currently, `agentscope-spark-design` publishes packages to npm via
manually triggered GitHub Actions, but **no corresponding Git Tags or
GitHub Releases are created** in this repository. This blocks our
internal adoption and compliance review.
## Request
We kindly request the maintainers to:
1. **Create Git Tags** for the current npm-published versions, e.g.:
- `@agentscope-ai/design@1.0.23` → tag `design-v1.0.23`
- `@agentscope-ai/chat@1.1.45` → tag `chat-v1.1.45`
2. **(Optional but preferred) Publish GitHub Releases** for these tags,
so enterprise users can pin to a stable, verifiable source point.
3. **(For long-term) Consider automating tag/release creation** as part
of the existing publish workflow, so each npm publish also produces
a corresponding Git Tag. This aligns with common OSS practices and
greatly helps enterprise adoption.
## Why this matters
- Enterprise compliance teams need **immutable, verifiable source points**
(Git Tags) to track dependency provenance.
- npm versions alone don't satisfy our internal audit requirements.
- A tagged commit lets us mirror the exact source into our internal
repository and build from source, which is our standard practice.
## Suggested implementation
The existing publish workflow could be extended to:
1. After `npm publish` succeeds, create a Git Tag matching the published
version (e.g., `design-v1.0.24`).
2. Optionally push the tag and let GitHub auto-generate Release notes.
This is a low-risk change to `.github/workflows/` and would greatly
improve enterprise usability.
## Additional context
- We've noticed CoPaw 1.0 also depends on this library, indicating it's
production-grade. Adding GitHub Releases would further strengthen its
enterprise readiness.
- We're happy to help test or contribute a PR if the maintainers agree
on the approach.
Thank you for considering this request!
Contributor guide
Research direction
Inspect the publish workflow files in `.github/workflows` to locate where `npm publish` runs and where to hook in release-related actions. Add a post-publish step to create and push tags in the `design-vX` / `chat-vX` format, then optionally include a release creation step for those tags. Validate by running the workflow and confirming the expected tags and releases appear in GitHub for those versions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, typescript
- Domain
- release
- Issue type
- Feature
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 72/100