Если в HEAD в composer.json будут зависимости, к примеру
{
"require": {
"symfony/console": "3.0"
}
}
А в dev-master#123abc
{
"require": {
"symfony/console": "~2.7"
}
}
То composer будет считать, что надо установить "symfony/console": "3.0" в качестве зависимости, хотя сам пакет будет установлен из указанного коммита. Это происходит потому. что пакет скачивается уже после того, как разрешены зависимости.
Note: While this is convenient at times, it should not be how you use packages in the long term because it comes with a technical limitation. The composer.json metadata will still be read from the branch name you specify before the hash. Because of that in some cases it will not be a practical workaround, and you should always try to switch to tagged releases as soon as you can.
То цитата из документации SemVer.
Теперь вижу, что не следуете. Точнее следуете по шаблону 2.MAJOR.MINOR.PATCH.
Только вот в composer разве можно указать "2.0.0.*"? В случае какой-то критической ошибки в безопасности появятся версии 2.0.0.1, 2.0.1.1 и тд? Или она будет устранена в 2.0.10?
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
Путь, несомненно, тёмный, но я так и не нашёл подходящего варианта, как заставить симфони подключить файл из библиотеки, которая не является бандлом. Буду благодарен за подсказку.
Давно уже не пользовался ассетиком, но вроде бы он умеет так (gulp так точно может):
А меня — автоматическое дополнение магазина. Единственная игра, которую знаю, где такого не было — мод Firearms для Half-Life. Часто получалось так, что у тебя есть 4 магазина, но в каждом из них по паре патронов.
Второй вариант не работает
Как обойтись без обратного вызова?
Если
То эквивалентом будет
Только в таком случае кеш бесполезен
Я бы еще конструктор сделал идентичный базовому:
А зачем в абстрактном классе
?
Можно же использовать \Symfony\Component\Console\Command\Command::getName
Первый вариант сразу вернет
PHP Parse error
(при чем не обязательно даже вызывать проблемную функцию)Второй вариант — только через 5 секунд.
Он устанвится, но его зависимости будут отрезолвены неверно.
В документации же все понятно:
Т.е. если указать
"kartik-v/yii2-export": "dev-master#47fd3e870a1b7c8dcfe572b8290b6c61011a6aa7"
То версия composer.json будет использована из мастера вместо https://github.com/kartik-v/yii2-export/blob/47fd3e870a1b7c8dcfe572b8290b6c61011a6aa7/composer.json, и если они отличаются, то будут проблемы
Если в HEAD в composer.json будут зависимости, к примеру
А в dev-master#123abc
То composer будет считать, что надо установить "symfony/console": "3.0" в качестве зависимости, хотя сам пакет будет установлен из указанного коммита. Это происходит потому. что пакет скачивается уже после того, как разрешены зависимости.
composer.json все равно будет считываться из указанной ветки, а не из коммита, так что это не всегда выход
https://getcomposer.org/doc/04-schema.md#package-links
Может помочь объявление своего пакета:
http://stackoverflow.com/questions/34784809/how-to-use-a-specific-tag-version-with-composer-and-a-private-git-repository
То цитата из документации SemVer.
Теперь вижу, что не следуете. Точнее следуете по шаблону 2.MAJOR.MINOR.PATCH.
Только вот в composer разве можно указать "2.0.0.*"? В случае какой-то критической ошибки в безопасности появятся версии 2.0.0.1, 2.0.1.1 и тд? Или она будет устранена в 2.0.10?
А что тогда означают 2.0.9?
Согласно документации:
Yii не следует SemVer? Немного странно видеть UPGRADE.md для патчей
Давно уже не пользовался ассетиком, но вроде бы он умеет так (gulp так точно может):
Тоже сначала так думал, но потом понадобилось сделать так:
{{ render_esi(controller('BloggerBlogBundle:Page:sidebar' )) }}
access_control: - { path: ^/club, role: [ROLE_CLIENT] }