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-master
while other packages with^1
or equivalent.It is possible to resolve modularity even if some packages requirs it with
dev-master
while other packages with^1
or equivalent.No.
Branch aliases in Composer are a very powerful tool.
Right now
inpsyde/modularity:dev-master
andinpsyde/modularity:1.0.0
refer to the exact same code. Still, if a package requires it withdev-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 comparedev-master
with^1
, becausedev-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 with1.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?)