I've created a v1.0.4 tag for my plug-in and deployer executed composer update on the server. After a short amount of time I've deleted this tag and created it again because this version needed a minor modification.
Now when deployer executes composer update on the server the plug-in is not been updated to the new v1.0.4 (that includes the modification) because the version number is still the same.
I've executed composer clear-cache on the server but this does not seem to work. Is this even possible or was it better to create a new version for this modification?
The modified tag v1.0.4 is present in the repository. Any help is appreciated.
Please tag your plugin properly as a new version. If v1.0.4 of it is already installed, the commit hash used by that tag is stored in composer.lock, and getting this fixed might lead to more problems popping up.
Related
I regularly observe the following behaviour:
When I try to execute composer update mynamespace/myproject, it fails because if conflicts with a dependent project "mynamespace/mydependency", which is 'locked' at a specific version - the version specified in the composer.lock file. I don't get what 'locked' means in that context, but I observe that the update works well once I deleted the entry
{
name : "mynamespace/mydependency"
...
}
from composer.lock. This behaviour is in contrast to what I understood so far that the composer.lock file was supposed to do - recording what exact versions are installed without specifiying any restrictions on composer.json.
Since my assumption has been proven wrong, I would be thankful to some clarification.
Never ever edit the lock file by hand, that will only cause trouble. If updating a single dependency does not work, you've found the reason already: cause it's still needed in the current version by any other dependency.
To see why an update is not possible, you can use composer why-not, followed by the package name and the version you want to update to. For example, the following command could list why exactly updating to v3 is not possible:
composer why-not mynamespace/myproject 3.0
Now, you can either decide to skip the update for now, or add any of the packages that are listed there to your update command such that these also receive an update.
NB: it's very common that updating a single component (and nothing else) is not possible, especially if this is not a minor update
I have to update CakePHP from current, outdated version (2.7.7) to latest on 2 branch, because of PHP7 support.
While I've done numerous framework upgrades before, I found book.cakephp.org a more than a cryptic about key things which I ask here:
can it be done by replacing directoris
which directories are intended to be replaced (never edit dirs, like system in Codeigniter)
which directories are partially replaced if any
is there SQL commands that should be run?
is there other commands that should be run?
Any clue is appreciated, but 2 and 3 are of most value I guess. Thanks in advance.
Depending on how you've installed CakePHP, you either use composer to update the CakePHP core dependency:
$ composer update
or require a specific constraint/version if your current constraint doesn't allow upgrading:
$ composer require cakephp/cakephp:^2.10.3
If you're not using composer (I'd suggest to switch to using it), then you download the latest release package manually, and completely replace the /lib/Cake directory. With respect to the core, the upgrade is then complete.
Then read the migration guides to figure the possible changes that you have to apply to your application code or database schemas, and also compare the "application template" changes (/app/) to your local application and apply changes in case necessary. After this, run your test suite to ensure that everything works as expected.
With that being said, the upgrade from 2.7 to the latest 2.10 should be pretty easy, as it is said to be fully API compatible.
I recommend you to use composer to manage your framework and extensions.
With composer installed, it would be much easier to update. If you decide to use composer, let me know if you need any more help by installation, setup or update.
Is there an automated way of updating the version number in composer.json and adding the necessary tags before publishing, like the way npm version does?
I mean, if you had a composer.json with the line "version": "2.1.3", and executed:
composer version minor
It would do the following:
Updating the version number in composer.json to 2.2.0
Triggering composer update to update composer.lock
Making a new git commit
Making a new git tag v2.2.0
I know that the composer version command doesn't exist, but is there an equivalent tool?
npm version does stuff that you very likely do not need for Composer:
The version number is not recorded in composer.json if there are other means available - and because you are referring to Git later on, they are available.
Updating dependencies in the lock file is unnecessary. The lock file will be ignored when the project you are dealing with is included somewhere else.
Because nothing has changed in the project, a git commit wouldn't do anything.
All this leaves you with creating a new tag in the Git repository. Putting this into Composer would mean you'd exchange one command with another, without any big benefit besides you won't have to lookup the current version number you are dealing with if you use some of the relative version parameters.
All in all I'd say that simply tagging your new version is enough for Composer. You'd probably need to have some infrastructure in place and configured to make the world aware of the new version:
If your package is open source and on packagist.org, you should have a post-commit hook to notify them as soon as a new version is available. This is a standard option on Github, I don't know about other source code hosts.
Otherwise if you have to feed closed source code, you'd probably start a new update cycle of whatever system is used to create an alternative package information source (be it Satis, locally hosted Packagist, Toran Proxy or Private Packagist)
This however depends on how you set up things.
If for some reason and despite all voices against it you still want to use a tool like the OP asked for, https://www.npmjs.com/package/composer-version works quite well.
I've made custom changes to a package (Its wrong, I know) and I want to preseve these changes every time I update composer .. How can I?
Tag that version in your own repository and depend on the tag without any wildcards. Composer will never try to grab a different commit then.
If you are unsure which version to use, and the upstream project didn't release a tagged version yet, start with 0.0.0. If you are basing your work on top of a tagged release X.Y.Z, you might tag your changes as X.Y.Z.1 and depend on that exact version.
I'm working with symfony2 for some time and I don't really get the correct way to work with the vendors.
So here is what I'm doing:
I have the deps and deps.lock files in my git while I ignore the whole vendors folder. Now when I install the application to a new server, I do a php bin/vendors install to pull the vendors onto the server. I get the message that I have to use install --reinstall and do that.
From my understanding, the versions should now be the exact same as on my development machine, as both deps and deps.lock are the same. But it seems that the deps.lock gets (partly) ignored?
There is also a vendors update command, which I read should not be used. BUt I didn't get the idea what it really does.
So I'm a bit confused now as of what command should be used when and what it is supposed to do. Maybe someone can shed some light on this topic! I'm especially interested in the correct way to use the vendors command both local and on the server so the vendors are in the correct version on both systems!
install and update both fetch new code from the git repositories specified in your deps file
install checks for hashes in you deps.lock files for each library. If it finds something, it checkouts the commit corresponding to the hash. If it does not, it checkouts the tag or branch in your deps.lock if one is specified and creates an entry in the deps.lock file
update is useful when you want to update to a new version of symfony (or any library in the deps file). If you one day, you feel like updating, you can read this post I wrote about the update process.
To sum up, I always use update on all machines, and I try to always specify a version for each library, so that the production environment does not get updated to an unstable version unexpectedly.
install --reinstall is the same as install but it also deletes vendor folder content before doing installation.
vendors update updates all your vendors to the latest version or version specified in your deps file and updates your deps.lock file. But you rarely need it, don't know where you read "should not be used".
If you look inside vendors file, you can see this line:
if (is_dir($vendorDir.'/symfony') && !is_dir($vendorDir.'/symfony/.git') && !in_array('--reinstall', $argv))
...Try to run ./bin/vendors install --reinstall...
So you have vendor/symfony folder without .git in it.
have you download the standard edition which already contains the vendors, that's why it displays this message to use "install - reinstall"
I personally made php bin / install-reinstall vendors in the deployement project