bdep-release(1)

📦
version 0.17.0 · 2 versions
, in fedora 43, fedora 44, nixos 26.05

💖 bdep-release(1) 💖

okay so welcome to the bdep-release page, bestie — straight out of the General Commands Manual and here to walk you through managing your project's version during release. no cap, this one's a whole journey. buckle up 🎀

✨ NAME ✨

bdep-release — manage project's version during release 💅

🦋 SYNOPSIS 🦋

bdep release [options] [prj-spec]

prj-spec = --directory|-d prj-dir | pkg-spec
pkg-spec = (--directory|-d pkg-dir)...

🌸 DESCRIPTION 🌸

so the release command is literally the main character of your project's version management during a release. here's the tea ☕: first it flips the snapshot version over to the matching release version in every project package's manifest file, commits those changes (unless you said --no-commit, bestie), tags that commit (unless --no-tag), and if --push is in the mix, it pushes the changes to the remote. then — unless --no-open is hanging around — the release command opens the next development cycle by switching the version to a snapshot, committing those changes (again, unless --no-commit), and, if --push was specified, pushing them to the remote. quick heads up though: committing, tagging, and pushing is currently only supported for git(1) project repositories. periodt.

you can also use the release command to ship a new package revision by passing the --revision option. in this mode, release bumps the revision component of the current version in each project package's manifest file, commits those changes (unless --no-commit), tags the commit (unless --no-tag), and if --push is specified, pushes everything to the remote. and in this mode you can optionally tell release to update an existing tag for the current version so it points at the latest revision (--current-tag=update) or to straight-up remove it (--current-tag=remove). choose your fighter ✨

when you're releasing a revision, the project's repository index is expected to already contain other changes, since for a revision all the associated changes — including the version change — must belong to a single commit. alternatively, you can release a revision by amending one or more existing commits using the --amend and --squash options. in that case the index may still contain additional changes, but it doesn't have to. lowkey flexible, honestly 🫶

the release command also has a bunch of continue modes that let you finish steps you previously suppressed with the --no-* options in the main modes above. those are --tag, which tags the release commit and, if --push is specified, pushes it to the remote too — and --open, which does the whole opening-the-next-development-cycle thing we described earlier. slay.

in all the modes that perform a commit: if the project's repository index already has other changes in it, then the commit message gets automatically opened for editing unless --no-edit is specified. and if you want the commit message opened even when there are no other changes? that's what the --edit option is for. iykyk 💅

normally, release operates on all the packages in a project. if no project directory is specified, then the current working directory is assumed and all the packages are released — even if the current directory is a package directory. if, however, one or more package directories are specified explicitly with --directory|-d, then release assumes you know what you're doing and only releases these packages. all the packages being released must have the same version, but they may have different revisions. no drama there ✨

👑 RELEASE OPTIONS 👑

  • --revision — release a new package revision instead of a new version. glow-up, but for your version number 💅
  • --no-commit — don't commit the changes. this one implies --no-tag and, in the version release mode, also implies --no-open.
  • --no-tag — don't tag the release commit. you can always tag later using the --tag mode option, no rush bestie.
  • --tag — tag the version that's already released instead of releasing a new one.
  • --current-tag action — tells release what to do with an existing tag for the current version when tagging a new revision. the valid values are keep (the default), update, and remove.
  • --push — push the committed changes and tags to the remote. send it 🚀
  • --show-push — print the push command instead of actually executing it. this lets you peek at the committed changes and tags before pushing them to the remote. note that the command is printed to stdout.
  • --no-open — don't open the next development cycle. you can do the opening later using the --open mode option.
  • --open — open the next development cycle instead of releasing a new version.
  • --amend — release a revision by amending the latest commit instead of making a brand new one.
  • --squash num — release a revision by squashing the specified number of previous commits and then amending the result. requires the --amend option to be specified.
  • --alpha — release an alpha instead of the final version.
  • --beta — release a beta version instead of the final version.
  • --minor — release the next minor version instead of the current patch.
  • --major — release the next major version instead of the current minor or patch.
  • --open-beta — open the development cycle with the next beta version.
  • --open-patch — open the development cycle with the next patch version. this is the default if the current patch version is not 0 (bugfix release series).
  • --open-minor — open the development cycle with the next minor version. this is the default if the current patch version is 0 (feature release series).
  • --open-major — open the development cycle with the next major version.
  • --open-base version — open the development cycle with the specified version. the base version should be in the major.minor.patch form, with the opened version becoming major.minor.patch-a.0.z.
  • --edit — open the commit message for editing.
  • --no-edit — don't open the commit message for editing.
  • --force check — force releasing, disabling the specified check. repeat this option to disable multiple checks. (live your truth, but maybe read the warnings first 👀)
  • --yes|-y — don't prompt for confirmation before releasing.
  • --directory|-d dir — assume the project/package is in the specified directory rather than in the current working directory.

🌈 COMMON OPTIONS 🌈

these are the shared ones, summarized below — the full detailed version lives over in bdep-common-options(1) if you wanna go deeper 🫶

  • -v — print essential underlying commands being executed.
  • -V — print all underlying commands being executed.
  • --quiet|-q — run quietly, only printing error messages. shhh 🤫
  • --verbose level — set the diagnostics verbosity to level between 0 and 6.
  • --stdout-format format — representation format to use for printing to stdout.
  • --jobs|-j num — number of jobs to perform in parallel.
  • --progress — display progress indicators for long-lasting operations, such as network transfers, building, etc.
  • --no-progress — suppress progress indicators for long-lasting operations, such as network transfers, building, etc.
  • --diag-color — use color in diagnostics.
  • --no-diag-color — don't use color in diagnostics.
  • --bpkg path — the package manager program to be used for build configuration management.
  • --bpkg-option opt — additional option to be passed to the package manager program.
  • --build path — the build program to be used to build packages.
  • --build-option opt — additional option to be passed to the build program.
  • --curl path — the curl program to be used for network operations.
  • --curl-option opt — additional option to be passed to the curl program.
  • --pager path — the pager program to be used to show long text.
  • --pager-option opt — additional option to be passed to the pager program.
  • --options-file file — read additional options from file.
  • --default-options dir — the directory to load additional default options files from.
  • --no-default-options — don't load default options files.

🧚 DEFAULT OPTIONS FILES 🧚

head over to bdep-default-options-files(1) for the full overview of default options files. for the release command specifically, the search start directory is the project directory. the following options files are searched for in each directory and, if found, loaded in the order listed:

bdep.options
bdep-release.options
bdep-release-{version|revision|open|tag}.options # (mode-dependent)

and the following release command options cannot be specified in the default options files, bestie:

--directory|-d
--revision
--open
--tag

💀 BUGS 💀

send bug reports to the users@build2.org mailing list. we love a good bug report, fr fr 🐛

Copyright (c) 2014-2024 the build2 authors.

Permission is granted to copy, distribute and/or modify this document under the terms of the MIT License.

and that's the whole page, bestie 🎀 this was bdep version 0.17.0, dated June 2024, and honestly? iconic. go release something gorgeous 👑✨🦋

📦 where this page comes from