dart-package-maintenance
Guidelines for maintaining external Dart packages, covering versioning, publishing workflows, and pull request management. Use when updating Dart packages, preparing for a release, or managing collaborative changes in a repository.
Packaged view
This page reorganizes the original catalog entry around fit, installability, and workflow context first. The original raw source lives below.
Install command
npx @skill-hub/cli install kevmoo-dash-skills-dart-package-maintenance
Repository
Skill path: .agent/skills/dart-package-maintenance
Guidelines for maintaining external Dart packages, covering versioning, publishing workflows, and pull request management. Use when updating Dart packages, preparing for a release, or managing collaborative changes in a repository.
Open repositoryBest for
Primary workflow: Ship Full Stack.
Technical facets: Full Stack.
Target audience: everyone.
License: Unknown.
Original source
Catalog source: SkillHub Club.
Repository owner: kevmoo.
This is still a mirrored public skill entry. Review the repository before installing into production workflows.
What it helps with
- Install dart-package-maintenance into Claude Code, Codex CLI, Gemini CLI, or OpenCode workflows
- Review https://github.com/kevmoo/dash_skills before adding dart-package-maintenance to shared team environments
- Use dart-package-maintenance for development workflows
Works across
Favorites: 0.
Sub-skills: 0.
Aggregator: No.
Original source / Raw SKILL.md
--- name: dart-package-maintenance description: |- Guidelines for maintaining external Dart packages, covering versioning, publishing workflows, and pull request management. Use when updating Dart packages, preparing for a release, or managing collaborative changes in a repository. --- # Dart Package Maintenance Guidelines for maintaining Dart packages in alignment with Dart team best practices. ## Versioning ### Semantic Versioning - **Major**: Breaking changes. - **Minor**: New features (non-breaking API changes). - **Patch**: Bug fixes, documentation, or non-impacting changes. - **Unstable packages**: Use `0.major.minor+patch`. - **Recommendation**: Aim for `1.0.0` as soon as the package is stable. ### Work-in-Progress (WIP) Versions - Immediately after a publish, or on the first change after a publish, update `pubspec.yaml` and `CHANGELOG.md` with a `-wip` suffix (e.g., `1.1.0-wip`). - This indicates the current state is not yet published. ### Breaking Changes - Evaluate the impact on dependent packages and internal projects. - Consider running changes through internal presubmits if possible. - Prefer incremental rollouts (e.g., new behavior as opt-in) to minimize downstream breakage. ## Publishing Process 1. **Preparation**: Remove the `-wip` suffix from `pubspec.yaml` and `CHANGELOG.md` in a dedicated pull request. 2. **Execution**: Run `dart pub publish` (or `flutter pub publish`) and resolve all warnings and errors. 3. **Tagging**: Create and push a git tag for the published version: - For single-package repos: `v1.2.3` - For monorepos: `package_name-v1.2.3` - Example: `git tag v1.2.3 && git push --tags` ## Pull Request Management - **Commits**: Each PR should generally correspond to a single squashed commit upon merging. - **Shared History**: Once a PR is open, avoid force pushing to the branch. - **Conflict Resolution**: Prefer merging `main` into the PR branch rather than rebasing to resolve conflicts. This preserves the review history and comments. - **Reviewing**: Add comments from the "Files changed" view to batch them. - **Local Inspection**: Use `gh pr checkout <number>` to inspect changes locally in your IDE.