Is this composer.json correct should it have dev-master in it

Question

I keep on getting error whenever update should i keep dev.. today as i updated i got another error for sonata admin which is discused https://groups.google.com/forum/#!topic/sonata-users/4AGVPyBMTSI my only question is it a good practise to keep dev in composer.json because all the lib which i go to install show dev-master in their documentation. I know this is very basic but i am new to composer and symfony2.. and not enjoying it a bit hahaha

{
    "name": "symfony/framework-standard-edition",
    "license": "MIT",
    "type": "project",
    "description": "The \"Symfony Standard Edition\" distribution",
    "autoload": {
        "psr-0": { "": "src/" }
    },
    "require": {
        "php": ">=5.3.3",
        "symfony/symfony": "~2.4",
        "doctrine/orm": "~2.2,>=2.2.3",
        "doctrine/doctrine-bundle": "~1.2",
        "twig/extensions": "~1.0",
        "symfony/assetic-bundle": "~2.3",
        "symfony/swiftmailer-bundle": "~2.3",
        "symfony/monolog-bundle": "~2.4",
        "sensio/distribution-bundle": "~2.3",
        "sensio/framework-extra-bundle": "~3.0",
        "sensio/generator-bundle": "~2.3",
        "incenteev/composer-parameter-handler": "~2.0",
        "friendsofsymfony/user-bundle": "1.3.*",
        "sonata-project/core-bundle": "~2.2@dev",
        "sonata-project/admin-bundle": "2.2.*@dev",
        "sonata-project/block-bundle": "dev-master",
        "sonata-project/cache": "1.*@dev",
        "sonata-project/cache-bundle": "2.2.*@dev",
        "sonata-project/jquery-bundle": "1.8.*@dev",
        "sonata-project/easy-extends-bundle" : "dev-master",
        "sonata-project/doctrine-orm-admin-bundle": "dev-master",
        "sonata-project/user-bundle": "dev-master"
    },
    "scripts": {
        "post-install-cmd": [
            "Incenteev\\ParameterHandler\\ScriptHandler::buildParameters",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile"
        ],
        "post-update-cmd": [
            "Incenteev\\ParameterHandler\\ScriptHandler::buildParameters",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile"
        ]
    },
    "config": {
        "bin-dir": "bin"
    },
    "extra": {
        "symfony-app-dir": "app",
        "symfony-web-dir": "web",
        "incenteev-parameters": {
            "file": "app/config/parameters.yml"
        },
        "branch-alias": {
            "dev-master": "2.4-dev"
        }
    }
}

Answer 1

You should avoid using named branches like dev-master if you don't actively develop that other software and know what's going on there.

Here's why: Today that branch might be the tip of the development of the 2.x version of a component. You happily update with Composer, and everything works fine.

Now that software decides that there will be a new major version released, and they start making backwards-incompatible changes. Now your own software that uses dev-master will point at that old commit of 2.x as long as you don't update anymore (or only update OTHER software explicitly), but in the long run things will break:

Because yet other components that you add might depend on that software in dev-master , but THEY mean the new 3.x development, your old software would satisfy that dependency, but not the code that is connected with it (remember: backwards-incompatible changes may also be forward-incompatible changes). So even without updating that particular component, things may at some point start breaking.

And if you blindly update the whole thing, you are even more likely to run into problems if such an update occurs.

Using version numbers in the dependencies is much easier. You can declare to require any version 2.* , which will prevent the update to any 3.x version, and it allows Composer to detect that a third component that depends on that 3.x version is incompatible with the older 2.x that is still installed. It will either lead to picking an older version that still depends on 2.x, or refuse to install it altogether. Which actually is a good thing because it allows you to manually update and see if things break (you do have tests, don't you?) - you can then fix them.

If you encounter a software you like, and the maintainers haven't yet tagged a version, please ask them nicely to do so. Either they respond with a tag, or you get the idea to search for another library that better suits your needs. Otherwise, expect to implicitly be part of their development team and help debugging their software (which can also be a good thing - but be prepared to spend that extra amount of time).