Use SemVer for Symfony versions
Symfony has one of the best BC promises in the PHP world. Which means it will be never a problem to allow all new minor versions of a supported major release.
To clear the considerations from https://review.typo3.org/#/c/46741/:
I'd go for ">=2.7|<3.1". 3.1 might deprecate functionality which will be unnoticed if we use ^3.0
Deprecations doesn't matter, they don't introduce regressions. Even if you update the version constraint by hand, you won't notice the deprecations by yourself without using the PHPUnit Symfony deprecation bridge.
A simple look in the according UPGRADE files should be enough if you want to remove the usage of deprecated functionality (which is no possible as long as you want to support older versions).
And looking at the used components (console and finder) they have no deprecations since the move to 3.0 (only console affected).
There isn't any version 3.1 yet. Please let us test those versions before raising core dependencies once there are available symfony versions.
Now it's here, and anyone has tested yet? No.
Will it break something? No.
Anyone has committed to be the responsible person doing the version constraint bump, when a new version is out? No!
TYPO3 problem is, that newest releases are not automatically tested in newer commits, because of the committed `composer.lock` file.
I disagree here. One will not be able to bump any of these dependencies in his own project since TYPO3 locks them down.
So one either has to 1) request a dependency bump in TYPO3 and hope for a quick release or 2) use inline version aliases to satisfy the lower TYPO3 dependencies.
I don't think we should prevent users from using newer versions of our dependencies like this.
And that's the point. Don't enforce users on specific minor versions of your deps, if there is a high possibility of depending on the same deps in their projects too. That's a bad move.
Especially to point 1. users are not used to the TYPO3 contribution workflow and are rather annoyed of your version lock. Point 2 is also a no go in the long term. Inline versions are only intended to be used while installing a fork for testing.