Please check if the PR fulfills these requirements
[x] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes/features)
[ ] Docs have been added/updated (for bug fixes/features)
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Non-code improvement.
What is the current behavior? (You can also link to an open issue here)
It is not possible to obtain an installable set of packages if one or more packages references modularity with dev-master while other packages with ^1 or equivalent.
What is the new behavior (if this is a feature change)?
It is possible to resolve modularity even if some packages requirs it with dev-master while other packages with ^1 or equivalent.
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
Right now inpsyde/modularity:dev-master and inpsyde/modularity:1.0.0 refer to the exact same code. Still, if a package requires it with dev-master and another with ^1 Composer will say it is not possible to resolve an installable set of packages.
The reason is simple: Composer can't compare dev-master with ^1 , because dev-master is not numeric and Composer has no idea what code it contains.
Thanks to branch aliases we can instruct Composer that what's in master branch is a "development version" comparable with 1.x and thanks to that Composer will be able to solve the puzzle.
Please note that because the alias is always for a "dev" version, when the "minimum stability" root config will be "stable" Composer will not pull the dev-master, no matter the branch alias, and that save us from the risk of having unreleased things in production (because we have "minimum stability" to stable in production, right?)
Please check if the PR fulfills these requirements
[x] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes/features)
[ ] Docs have been added/updated (for bug fixes/features)
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Non-code improvement.
It is not possible to obtain an installable set of packages if one or more packages references modularity with
dev-masterwhile other packages with^1or equivalent.It is possible to resolve modularity even if some packages requirs it with
dev-masterwhile other packages with^1or equivalent.No.
Branch aliases in Composer are a very powerful tool.
Right now
inpsyde/modularity:dev-masterandinpsyde/modularity:1.0.0refer to the exact same code. Still, if a package requires it withdev-masterand another with^1Composer will say it is not possible to resolve an installable set of packages. The reason is simple: Composer can't comparedev-masterwith^1, becausedev-masteris not numeric and Composer has no idea what code it contains.Thanks to branch aliases we can instruct Composer that what's in
masterbranch is a "development version" comparable with1.xand thanks to that Composer will be able to solve the puzzle.Please note that because the alias is always for a "dev" version, when the "minimum stability" root config will be "stable" Composer will not pull the
dev-master, no matter the branch alias, and that save us from the risk of having unreleased things in production (because we have "minimum stability" to stable in production, right?)