Updating single packages is very much possible, see https://getcomposer.org/doc/03-cli.md#update - as for semver promises, that's really up to you and which packages you decide to trust, nothing the tool can do about it.
Note I said "deal with", it's not update, I learned long ago never to touch composer update. I think it is require that does this. Or that install doesn't have a single package argument? Whatever. I am not alone in finding the only way to actually use composer is to nail down every single package to a single version. Do note I didn't write https://github.com/webflo/drupal-core-strict which is just that https://github.com/webflo/drupal-core-strict/blob/8.5.4/comp...
As for trust, noone in the PHP world! Absolutely noone! I got into a debate with Rasmus about the meaning of backwards compatibility around the time PHP 5.4 began to throw additional warnings (not a new class of errors which could be additionally displayed, no) on code that previously worked. Drupal 8.4 released with a known bug that caused some code to merrily lose files uploaded by users because of a BC break. If you want BC, look at the kernel Linux API and even the ABI.
IMO for the first point you should rather use ^x.y with the minimum version you require and then accept new releases as they come. If you do regular updates you should notice quickly when something break and be able to revert that update easily. If you update 20 packages at once it becomes harder to pinpoint where a regression occurred.
As for including the vendor dir in your VCS repo, this comes with quite a few drawbacks. That's one of the things Private Packagist (https://packagist.com) aims to fix though, as it keeps mirrored copies of your dependencies' zip archives so you get more reliable installs.
If you are talking about such long time frames, then indeed archiving a project with its vendor directory might be a good idea once you decide to relegate it to the freezer.
How about "vendor decided to migrate off Github last week, and managed to break all their tags in the process"? (Not that this would have actually happened to me this Monday, noooo ;)) Long timeframes are not the only issue with external dependencies...
You don't need (and shouldn't depend on) packagist when using Composer. You can import packages directly from Github, Bitbucket, etc., or even locally, you just have to write a bit more JSON.
Rewrite your composer.json to include them directly?. The lock file probably contains the actual repository URLS so once you have a dependency tree resolved you can rewrite it based on that.
But it is possible to avoid packagist. Ugly and painful maybe but possible, and YMMV regarding the effort being worth the reward. Dependency management in PHP isn't (or shouldn't be) like it is with JS/Node where there is one authoritative registry that everyone has to depend on and that can assert direct influence over the community as a result. Packagist shouldn't be the PHP package registry, but a registry.
The fact that I need packagist, and the basic structure is really easy to copy? If not packagist, then someone will have set up a package repository with a different name.
I think PHPStorm from JetBrains is the IDE of choice of most PHP devs using IDEs at this point. They completely own the market, and rightfully so (I'm still stuck on Sublime Text myself, but wouldn't consider any other IDE than PHPStorm if I were to use one).
For those looking for a technical explanation, the PHP garbage collector in this case is probably wasting a ton of CPU cycles trying to collect thousands of objects (a LOT of objects are created to represent all the inter-package rules when solving dependencies) during the solving process. It keeps trying and trying as objects are allocated and it can not collect anything but still has to check them all every time it triggers.
Disabling GC just kills the advanced GC but leaves the basic reference counting approach to freeing memory, so Composer can keep trucking without using much more memory as the GC wasn't really collecting anything. The memory reduction many people report is rather due to some other improvements we have made yesterday.
As to why the problem went unnoticed for so long, it seems that the GC is not able to be observed by profilers, so whenever we looked at profiles to improve things we obviously did not spot the issue. In most cases though this isn't an issue and I would NOT recommend everyone disables GC on their project :) GC is very useful in many cases especially long running workers, but the Composer solver falls out of the use cases it's made for.
As to why the problem went unnoticed for so long, it seems that the GC is not able to be observed by profilers, so whenever we looked at profiles to improve things we obviously did not spot the issue.
That sounds like a bug in the profiler, not with Composer. Observing internal time is pretty important for any profiler.
That would help speed up the network part of the install/update yes. The linked patch on the other hand hopefully gets the CPU part to a decent level for most people.
Out of curiosity what tools do you use for profiling and finding these sorts of things? Plain old xdebug, xhprof, or other things? I'm going to have to jump into debugging a fairly large Symfony application within the next couple months and am on the look out for good tools to help me along.
There is a bit of history and context needed here I think. The last Opera 12 was released about a year ago. Last year they announced they would switch to using Blink instead of their own rendering engine.
The engine switch came with a complete rewrite of their browser as far as I understand it, so they prioritized Windows/OSX stability for a year and now finally came up with a Linux build again. The big gap in version numbers is due to their new browser starting at 15 + the adoption of a much shorter release cycle.
Once Linux builds are made stable I expect they will continue to release builds on all 3 platforms as they were doing for the many years before this slightly extreme shift.
Also note that it's available through the regular settings UI (opera://settings/) if you enable advanced settings under User Interface you will find "Disable tab bar's top spacing when browser window is maximized".
