القائمة
Defines conventions for releasing open-source SDKs and libraries. Use when releasing a new version of an SDK, writing changelogs, or publishing to a language registry (npm, PyPI, Maven, etc.).
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | sdk-release |
| description | Defines conventions for releasing open-source SDKs and libraries. Use when releasing a new version of an SDK, writing changelogs, or publishing to a language registry (npm, PyPI, Maven, etc.). |
Called by sdk-implement Phase 7.
Rules: safety · change-control
Use Semantic Versioning:
0.1.0 for new packages.0.x, breaking changes bump minor (e.g., 0.1.0 → 0.2.0).Convention: altertable-{lang} for product analytics SDKs (default product). altertable-{product}-{lang} for other product SDKs (e.g., altertable-lakehouse-ruby).
Package names, registries, and repository mappings are defined in repositories.config.json.
Note: the JS/TS SDK and web framework wrappers live in the altertable-js monorepo under packages/ — that repo publishes multiple packages.
Follow Keep a Changelog format:
# Changelog
## [Unreleased]
### Added
- New feature description.
### Changed
- Changed behavior description.
### Fixed
- Bug fix description.
### Removed
- Removed feature description.
Rules:
Added, Changed, Fixed, Removed).[0.2.0]: https://github.com/altertable-ai/altertable-js/compare/v0.1.0...v0.2.0).Use release-please GitHub Action for:
Because Altertable squash-merges pull requests and release-please derives release notes and version bumps from the merged commit subject, every repository using release-please must validate pull request titles in CI. The required gate is a dedicated GitHub Actions workflow using amannn/action-semantic-pull-request@v5, triggered on pull_request_target for opened, edited, and synchronize. Allowed title types are:
featfixperfrevertdocsstylechorerefactortestbuildciName the workflow clearly (for example Semantic Pull Request), keep it separate from language-specific CI when possible, and treat missing PR-title validation as release automation drift that must be patched across affected repositories. The canonical workflow is managed by sdk-sync at skills/sdk-sync/templates/.github/workflows/semantic-pr.yml.
Commit message prefixes:
| Prefix | Version Bump |
|---|---|
fix: | Patch |
feat: | Minor |
feat!: | Major |
npm (JS/TS):
"sideEffects": false for tree shaking.exports field.types field pointing to declarations.files array to allowlist published files.PyPI (Python):
pyproject.toml with [build-system] section.py.typed marker for typed packages.Maven Central (Java/Kotlin):
crates.io (Rust):
cargo publish --dry-run before release.All packages use the MIT license. Include LICENSE file at the package root.
Generate a weekly status summary covering PRs opened/merged/closed by Albert, issues triaged, spec alignment progress, and blockers awaiting human input.
Triage incoming GitHub issues across supervised Altertable repositories. Use when processing new issues, labeling bugs and feature requests, detecting duplicates, requesting minimal reproductions, or marking stale issues.
Notification-driven maintainer routine to identify actionable work across supervised Altertable repositories. Relies on GitHub notifications and API to monitor activity and respond to issues and PRs requiring attention. Use when starting a maintenance session to process notifications and prioritize work.
Bootstrap or update an Altertable SDK repository from a versioned API spec. Use when given a target GitHub repository (e.g. altertable-ai/altertable-lakehouse-ruby) and a spec version tag (e.g. v0.1.0) to set up a git submodule, implement missing functionality, and submit a PR. Also use when a new spec version is released and the SDK needs to be updated to match.
Keep shared configuration, community files, and CI templates consistent across all SDK repositories. Use when auditing cross-repo consistency or propagating a change (license, contributing guidelines, CI updates, bot config) to multiple SDK repos.
Review community pull requests against Altertable SDK standards. Use when reviewing contributor PRs, checking naming conventions, test coverage, changelog entries, and deciding whether to approve, request changes, or close.