Detect the `"branch-alias"` for the current `--to`, and define whether BC breaks should be allowed or not

[Ocramius]

This is probably interesting for @Majkl578.

Given following `composer.json`
{
    "extra": {
        "branch-alias": {
            "develop": "3.x-dev",
            "master": "2.x-dev"
        }
    }
}
And a tag `2.2.0` exists
And `HEAD` is `master`
When we run `bin/roave-backward-compatibility-check`
Then the current version will be considered to be `2.99999.99999.99999.99999.99999`
And BC break analysis will be enforced

Given following `composer.json`
{
    "extra": {
        "branch-alias": {
            "develop": "3.x-dev",
            "master": "2.x-dev"
        }
    }
}
And a tag `2.2.0` exists
And `HEAD` is `develop`
When we run `bin/roave-backward-compatibility-check`
Then the current version will be considered to be `3.99999.99999.99999.99999.99999`
And BC break analysis will not be enforced

This kind of tweak will allow consumers of the package to just drop it into their .travis.yml, and it will encourage clean declaration of "branch-alias" for everyone to read and understand.

This should probably also be skippable with a flag, since we don't want the inferred version to be always detected, and sometimes we really always want a non-zero exit code in case of BC breaks, even if the branch alias declares a major version bump.

Also, this behavior should be skipped if --from is defined.

@nikolaposa this is also interesting for the version lib btw - unsure if the version lib can help with parsing branch aliases...

[Ocramius]

Turns out that the utilities in composer/semver do fit our use-case scenario here: will give it a stab while traveling back home.

[nikolaposa]

ATM Version lib is handling everything described in the https://semver.org/. So everything from major.minor.patch numbers, over pre-release identifiers to build metadata.

I think that composer/semver is specialized for Composer's or package manager use cases in general. Anyway, Composer\Semver\VersionParser::normalize() is something I might consider using as an additional version string parsing strategy in my library.

[acrobat]

@Ocramius this looks like an intresting feature and one I could use! If this is not already in progress I would like to help, but do you have some pointer on how you wanted to solve this (as I'm not really familiar with the internals of this tool)?

[Ocramius]

@acrobat nothing better than digging into the code.

I suggest looking at bin to figure out each component: the tool uses dependency injection, so each class has relatively isolated responsibilities.