magento
magento copied to clipboard
Make branches composer compliant
The branches should be composer compliant like in https://github.com/bragento/magento-core. This leads to automatically generated dev - Versions pointing to each branch Thanks to @davidverholen for idea in #27
@SchumacherFM @therouv @AydinHassan what are you thoughts about it?
Yes do it
If you do it that way then how do you patch a minor version of Magento? Using your current branch process you can patch 1.9.1.0 and 1.9.1.1 exclusively. If I'm not mistaken the approach at https://github.com/bragento/magento-core does not allow to patch old versions, only the most recent 1.x release.
yes, that's right. We don't need them because we are always using the latest minor version of a major version.
Since Magento 1 does not use semantic versioning, you could also create dev branches like: 1.9.0 1.9.1 ...
I'm not sure if it would make sense to patch 1.9.1.0 when 1.9.1.1 is released. Since that release should be bug- and security fixes only, you should not use 1.9.1.0 anymore. Correct me if I'm wrong here.
Look here we use +
as separator between version number and patch number:
for example v1.7.0.2+patch2
I think the current way is the best way. Although you shouldn't use 1.9.1.0 when 1.9.1.1 is released, we can't guarantee it is not a BC upgrade due to the fact that Magento doesn't support semver.
@razbakov Does using +patch*
get pulled in automatically when using say ~1.9
? I know -patch*
does but +
isn't mentioned in the docs
yes, it's pulled
~1.7
will pull 1.9.2.2
because of semver
but if you specify 1.7.*
then v1.7.0.2+patch1
will be used
+
is build metadata
you could also use ~1.7.0 to get the latest 'subversion' under 1.7
you can of course also have branches for each magento version.
Then either drop the magento prefix or create a branch alias for every branch so the dev versions point to the correct branches.
https://getcomposer.org/doc/articles/aliases.md
That's exactly what this issue is about. I will fix it ASAP.