Download the PHP package liip/rmt without Composer

On this page you can find all versions of the php package liip/rmt. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.


After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

All versions of rmt with dependencies

Informations about the package rmt

RMT - Release Management Tool

Build Status Latest Stable Version Total Downloads License

RMT is a handy tool to help releasing new versions of your software. You can define the type of version generator you want to use (e.g. semantic versioning), where you want to store the version (e.g. in a changelog file or as a VCS tag) and a list of actions that should be executed before or after the release of a new version.


Option 1: As a development dependency of your project

In order to use RMT in your project you should use Composer to install it as a dev-dependency. Just go to your project's root directory and execute:

composer require --dev liip/rmt

Then you must initialize RMT by running the following command:

php vendor/liip/rmt/command.php init

This command will create a .rmt.yml config file and a RMT executable script in your project's root folder. You can now start using RMT by executing:


Once there, your best option is to pick one of the configuration examples below and adapt it to your needs.

If you are using a versioning tool, we recommend to add both Composer files (composer.json and composer.lock), the RMT configuration file(.rmt.yml) and the RMT executable script to it. The vendor directory should be ignored as it is populated when running composer install.

Option 2: As a global Composer installation

You can add RMT to your global composer.json and have it available globally for all your projects. Therefor just run the following command:

composer global require liip/rmt

Make sure you have ~/.composer/vendor/bin/ in your $PATH.

Option 3: As a Phar file

RMT can be installed through phar-composer, which needs to be installed therefor. This useful tool allows you to create runnable Phar files from Composer packages.

If you have phar-composer installed, you can run:

sudo phar-composer install liip/RMT

and have phar-composer build and install the Phar file to your $PATH, which then allows you to run it simply as rmt from the command line or you can run

phar-composer build liip/RMT

and copy the resulting Phar file manually to where you need it (either make the Phar file executable via chmod +x rmt.phar and execute it directly ./rmt.phar or run it by invoking it through PHP via php rmt.phar.

For the usage substitute RMT with whatever variant you have decided to use.

Option 4: As Drifter role

If your are using for your project, you just need three step


Using RMT is very straightforward, just run the command:

./RMT release

RMT will then execute the following tasks:

  1. Execute the prerequisites checks
  2. Ask the user to answers potentials questions
  3. Execute the pre-release actions
  4. Release
    • Generate a new version number
    • Persist the new version number
  5. Execute the post-release actions

Here is an example output:


Additional commands

The release command provides the main behavior of the tool, additional some extra commands are available:


All RMT configurations have to be done in .rmt.yml. The file is divided in six root elements:

All entries of this config work the same. You have to specify the class you want to handle the action. Example:

version-generator: "simple"`
       tag-prefix: "v_"

RMT also support JSON configs, but we recommend using YAML.

Branch specific config

Sometimes you want to use a different release strategy according to the VCS branch, e.g. you want to add CHANGELOG entries only in the master branch. To do so, you have to place your default config into a root element named _default, then you can override parts of this default config for the branch master. Example:

    version-generator: "simple"
    version-persister: "vcs-tag"
    pre-release-actions: [changelog-update]

You can use the command RMT config to see the merge result between _default and your current branch.

Version generator

Build-in version number generation strategies.

Version persister

Class in charge of saving/retrieving the version number.

Prerequisite actions

Prerequisite actions are executed before the interactive part.


Actions can be used for pre or post release parts.

Extend it

RMT is providing some existing actions, generators, and persisters. If needed you can add your own by creating a PHP script in your project, and referencing it in the configuration via it's relative path:

version-generator: "bin/myOwnGenerator.php"

Example with injected parameters:

    name: "bin/myOwnGenerator.php"
    parameter1: value1

As an example, you can look at the script /bin/UpdateApplicationVersionCurrentVersion.php configured here.

WARNING: As the key name is used to define the name of the object, you cannot have a parameter named name.

Configuration examples

Most of the time, it will be easier for you to pick up an example below and adapt it to your needs.

No VCS, changelog updater only

version-generator: semantic
version-persister: changelog

Using Git tags, simple versioning and prerequisites

vcs: git
version-generator: simple
version-persister: vcs-tag
prerequisites: [working-copy-check, display-last-changes]

Using Git tags, simple versioning and composer-prerequisites

vcs: git
version-generator: simple
version-persister: vcs-tag
    - composer-json-check
    - composer-stability-check:
        stability: beta
    - composer-dependency-stability-check:
            - [symfony/console]
            - [phpunit/phpunit, require-dev]

Using Git tags, simple versioning and prerequisites, and gpg sign commit and tags

  name: git
  sign-tag: true
  sign-commit: true
version-generator: simple
version-persister: vcs-tag
prerequisites: [working-copy-check, display-last-changes]

Using Git tags with prefix, semantic versioning, updating two files and pushing automatically

vcs: git
version-generator: semantic
    name: vcs-tag
    tag-prefix : "v_"
        - [config.yml]
        - [app.ini, 'dynamic-version: %version%']
post-release-actions: [vcs-publish]

Using semantic versioning on master and simple versioning on topic branches, markdown formatting for changelog

    vcs: git
    prerequisites: [working-copy-check]
    version-generator: simple
        name: vcs-tag
        tag-prefix: "{branch-name}_"
    post-release-actions: [vcs-publish]

# This entry allow to override some parameters for the master branch
    prerequisites: [working-copy-check, display-last-changes]
            format: markdown
            dump-commits: true
            class: Doctrine\ODM\PHPCR\Version
            pattern: const VERSION = '%version%';
        vcs-commit: ~
    version-generator: semantic
    version-persister: vcs-tag


If you would like to help, by submitting one of your action scripts, generators, or persisters. Or just by reporting a bug just go to the project page

If you provide a PR, try to associate it some unit or functional tests. See next section



To be able to run the tests locally, you need:

You can install all of them with Brew:

> brew install phpunit git hg

The tests are also testing the creation of the RMT phar. So you have to allow this in your php.ini, by uncommenting this line:

phar.readonly = Off

Finally, to run the tests, just launch PHPUnit

> phpunit

Functional tests

The functional tests are fully functional temporary RMT setup. Each time you run functional test, it creates a temporary folder with a RMT project. Then the test suite is running RMT commands on it, and check the results. That's why you need to have Git and Mercurial installed.


To debug RMT functional tests, the best is to go into this temporary folder and manually explore the project. To do so, just add a small $this->manualDebug(); into the test suite. This will break the test with the following output:

> cd /private/var/folders/hl/gnj5dcj55gbc93pcgrjxbb0w0000gn/T/ceN2Mf

Then you just have to go into the mentioned folder and start debugging



RMT is licensed under the MIT License. See the LICENSE file for details.

Requires ext-json Version *
php Version ^7.1|^8.0
symfony/console Version ^3.4|^4.0|^5.0|^6.0
symfony/yaml Version ^3.4|^4.0|^5.0|^6.0
symfony/process Version ^3.4|^4.0|^5.0|^6.0
vierbergenlars/php-semver Version ^3.0.2

The package liip/rmt contains the following files

Loading the files please wait ....