standard-library/sdk-framework

1.0.30 2026-08-03 14:45 UTC

Requires

• php: ^8.5.0
• ext-curl: *
• standard-library/sdk: ^1.0.30

MIT

Published on Packagist.org on 2026-08-03 18:36 UTC

README

Release automation for PHP Standard Library packages: version bumping and GitLab tag creation. require it as a dev dependency and it contributes commands to bin/sdk (from standard-library/sdk) — it has no bin/ scripts of its own.

{
  "require-dev": {
    "standard-library/sdk-framework": "^1.0"
  }
}

Commands

Command	Purpose
bin/sdk bump-version <version>	Bump the package version everywhere it's referenced.
bin/sdk tag-release <version>	Create a version tag on every package's GitLab repository.

Run either one in Docker with --docker (e.g. bin/sdk tag-release 1.2.0 --docker) — see standard-library/sdk's README for the -d/--docker[=IMAGE] option.

Release automation

bump-version and tag-release are both driven by a gitlab/packages config, each read from the section of config-dev.yaml keyed by that command's own fully qualified class name — like every other Console\Command. Since both commands need the same gitlab/packages data, define it once via a YAML anchor and merge it into both sections:

.release: &release
  gitlab:
    host: gitlab.com

  packages:
    foo:
      localPath: packages/foo
      remotePath: my-org/release-packages/foo
    bar:
      localPath: packages/bar
      remotePath: my-org/release-packages/bar

'StandardLibrary\Sdk\Framework\Console\Command\BumpVersionCommand':
  vendorName: my-org
  <<: *release

'StandardLibrary\Sdk\Framework\Console\Command\TagReleaseCommand':
  <<: *release

• packages maps a package name to its localPath (relative to the project root; must contain a composer.json) and remotePath (its full GitLab project path, <group>/<repo>).
• gitlab.host + a package's remotePath form the GitLab API URL used for tagging (https://<gitlab.host>/api/v4/projects/<remotePath>/...).
• bump-version additionally requires its own vendorName.

bin/sdk bump-version <version>

Bumps every "<vendorName>/<anything>": "^X.Y.Z" require constraint to the new version, in each package listed under release.packages' own composer.json — matched purely by the vendorName prefix, so it also catches requires on internal packages that aren't themselves declared in release.packages. It does not write a "version" field into any composer.json — Composer treats git tags as the source of truth for a VCS-installed package's version, and an explicit "version" field would just get out of sync with the tag tag-release creates.

It also bumps "<vendorName>/<anything>": "dev-main as X.Y.Z" aliases in the project's root composer.json, if present — the convention this monorepo uses to develop packages in lockstep via path repositories. That step is a no-op for projects that don't use it.

bin/sdk fm:tag-release <version>

Creates a <version> git tag (default ref: main) on every package's GitLab project via the GitLab REST API. Prompts for a GitLab API token with API access to those projects (input is hidden, like a password prompt) rather than reading it from an environment variable:

$ bin/sdk fm:tag-release 1.2.0
GitLab API token:

For non-interactive use (e.g. CI), pipe the token into stdin instead:

echo "$GITLAB_API_TOKEN" | bin/sdk fm:tag-release 1.2.0

The command exits non-zero and lists which packages failed if any tag couldn't be created.