PHPackages                             20steps/versioning-bundle - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. 20steps/versioning-bundle

ActiveSymfony-bundle

20steps/versioning-bundle
=========================

Symfony3 application versioning, simple console command to manage version (with handlers e.g. git tag) of your application using Semantic Versioning 2.0.0 recomendations

1.4.2(9y ago)071MITPHPPHP >=5.3.3

Since Jul 23Pushed 8y ago3 watchersCompare

[ Source](https://github.com/20steps/versioning-bundle)[ Packagist](https://packagist.org/packages/20steps/versioning-bundle)[ Docs](https://github.com/shivas/versioning-bundle)[ RSS](/packages/20steps-versioning-bundle/feed)WikiDiscussions master Synced 4d ago

READMEChangelogDependencies (4)Versions (12)Used By (0)

versioning-bundle
=================

[](#versioning-bundle)

[![SensioLabsInsight](https://camo.githubusercontent.com/c1d43110905c8bd59c39e4b5a2c2bc9076b5fc03a1a1fa897246f623de3cabdf/68747470733a2f2f696e73696768742e73656e73696f6c6162732e636f6d2f70726f6a656374732f64366437333337362d623832362d343664302d383566352d6664396637376334356330362f6d696e692e706e67)](https://insight.sensiolabs.com/projects/d6d73376-b826-46d0-85f5-fd9f77c45c06)[![Total Downloads](https://camo.githubusercontent.com/7cd8dd59af810ef226f35f3427cf61e89d38eb4a2299f05b47699268db4c545e/68747470733a2f2f696d672e736869656c64732e696f2f7061636b61676973742f64742f7368697661732f76657273696f6e696e672d62756e646c652e7376673f7374796c653d666c6174)](https://packagist.org/packages/shivas/versioning-bundle)

Simple way to version your Symfony2 application.

What it is:
-----------

[](#what-it-is)

- Adds additional parameter to your parameters.yml file and keeps it inline with your current application version.
- Basic Version handlers implemented for manual and *git tag* versioning
- Easy to extend with new handlers for different SCM's or needs
- Uses Semantic Versioning 2.0.0 recommendations using  library
- Uses Symfony console component to create command, can be easily integrated with Capifony to update version on every deployment

Purpose:
--------

[](#purpose)

To have parameter in your Symfony2 application with current version of application for various needs:

- Display in frontend
- Display in backend
- Anything you can come up with

Handlers implemented:
---------------------

[](#handlers-implemented)

- ParameterHandler (to manage version manually using app:version:bump command)
- GitRepositoryHandler (git tag describe hangler to automaticly update version looking at git tags)
- InitialVersionHandler (just returns default initial version 0.1.0)

Install
-------

[](#install)

run composer.phar update

```
php composer.phar require shivas/versioning-bundle

```

Add bundle to your AppKernel

```
new Shivas\VersioningBundle\ShivasVersioningBundle()

```

run in console:

```
# This will display of available handlers for version bumping
./app/console app:version:bump -l

```

```
# to see dry-run
./app/console app:version:bump -d

```

Default configuration
---------------------

[](#default-configuration)

Default configuration of bundle looks like this:

```
./app/console config:dump ShivasVersioningBundle
Default configuration for "ShivasVersioningBundle"
shivas_versioning:
    version_parameter:    application_version
    version_file:         parameters.yml

```

That means in the parameters file the `application_version` variable will be created and updated on every bump of version, you can change the name to anything you want by writing that in your config.yml file. You may also specify a file other than `parameters.yml` if you would like to use a custom file. If so, make sure to import it in your config.yml file - you may want to use `ignore_errors` on the import to avoid issues if the file does not yet exist.

```
    # app/config/config.yml
    imports:
        - { resource: sem_var.yml, ignore_errors: true }

    shivas_versioning:
        version_file:  sem_var.yml
```

Git Handler
-----------

[](#git-handler)

Git handler works only when you have atleast one TAG in your repository, and all TAGS used for versioning should follow SemVer 2.0.0 notation with exception, that git handler allows letter "v" or "V" to be used in your tags, e.g. v1.0.0

Application version from git tag are extracted in following fashion:

- v or V is stripped away
- if commit sha matches last tag sha then tag is converted to version as is
- if commit sha differs from last tag sha then following happens:
    - tag is parsed as version
    - prerelease part of SemVer is added with following data: "-dev.abcdefa"
    - where prerelease part "dev" means that version is not tagged and is "dev" stable, and last part is commit sha

This is default behavior and can be easily changed anyway you want (later on that)

Displaying version
------------------

[](#displaying-version)

To display version for example in page title you can add following to your config.yml:

```
twig:
    globals:
        app_version: v%application_version%
```

And then, in your Twig layout display it as global variable:

```
{{ app_version }}
```

Alternatively, if you want to display version automatically without having to bump it first, set `config.yml` to :

```
twig:
    globals:
        shivas_manager: '@shivas_versioning.manager'
```

And then, in your Twig layout:

```
{{ shivas_manager.version }}
```

The downside is the app version will be computed every time a twig layout is loaded, even if the variable is not used in the template. However, it could be useful if you have rapid succession of new versions or if you fear to forget a version bump.

Adding own handlers
-------------------

[](#adding-own-handlers)

It's easy, write a class that implements HandlerInterface:

```
namespace Acme\AcmeBundle\Handler;

use Shivas\VersioningBundle\Handler\HandlerInterface;

class MyCustomHandler implements HandlerInterface
{

}
```

For example, lets modify how git handler adds prerelease data to version if tag is outdated, instead just add "build" part with git commit sha. We gonna reuse big part of git handler and just override method for metadata handling:

```