This avoids using external locks, which are prone to platform issues
(race conditions and tombstones for lock files or missing semaphore extension)
and instead directly uses the file locking mechanism of PHP to lock the cache files.

This should noticeably improve performance for the FileBackend caches and avoid
having thousands of Lock files which clobber the file system and created issues
with big setups previously.

This introduces a simple type converter which can convert
a scalar value (string, integer, float or boolean) into an
object by passing that value to the class constructor.

This converter helps developers using Value Objects (not
managed by the persistence framework) or other Data
Transfer Objects in places where type conversion is
supported. One common case is to use Value Object class
names as a type hint for arguments in a command line
controller method.

Creating a new TypeConverter can have major side-effects on existing applications.
This change allows TypeConverters to have a negative priority in order to mark them “internal”.
Internal TypeConverters will be skipped from PropertyMapping by default.

Marking classes final is an important tool for framework code as it allows to define extension points
more explicitly, but until now we had to avoid the final keyword in order to support DI and AOP.

ViewConfiguration use only the settings of highest weighted request filter¶

Before this the higher weighted requestFilters were merged into the lower-weighted ones which placed the array-properties of the higher weighted filters last in the merged configuration. This made it impossible to add a new path templatePath that would be considered before.

This patch removes the merging of view-configurations entirely since this lead to confusion in the integration because the merging was unexpected.

This is breaking if you have multiple configurations with filters that apply to the same request and expect some option from one of the configurations to still be present despite another configuration having a higher weight.

The old resource management pre Flow 3.0 used the ResourcePublisher
as main service to get public URLs to resources and the ResourcePointer
to keep track of unique resources. Both became unnecessary and were
deprecated with Flow 3.0 and are therefore removed with this major release.

The CacheManager::getClassTag method was unused since
quite some time and became deprecated in previous releases.
It is therefore bound for removal in this major version.
Additionally the unused tagging constants in the FrontendInterface
are removed as they are also no longer needed.

This renames the class Resource to ResourceObject and renames the namespaces
TYPO3\\Flow\\Object and TYPO3\\Flow\\Resource to TYPO3\\Flow\\ObjectManagement
and TYPO3\\Flow\\ResourceManagement respectively.

A Doctrine migration and two core migrations to help with adjusting code are added.

Since the Request and Response instances are supposed to change inside the ComponentChain,
it is error-prone to keep a reference to the initial instances inside the RequestHandler.
This change removes the class properties $request and $response and instead uses local variables.

This is marked breaking only for the reason that some RequestHandler implementations could
exist that still somehow depend on this internal detail. It is not really breaking as those properties
were never part of the public api though.

This is a breaking change for installations that had accounts created with a Flow version lower
than 1.1 (and whose passwords were never updated since then).
In that case make sure to add the prefix to the corresponding accounts in the accounts table.
For the default configuration the corresponding SQL query would be:

Due to some problems caused by older Flow installations that migrated from 1.0, a fallback
mechanism for the password hashing strategies was implemented for password hashes that don’t
contain the strategy prefix (i.e. “bcrypt=>”).

As a result the default strategy for HashService::hashPassword() is a different one than for
HashService::validatePassword() unless specified explicitly because for the latter the configured
fallback strategy would be used rather than the default.

There have been major API changes in Flow 4.0 which require your code to be adjusted. As with earlier changes to Flow
that required code changes on the user side we provide a code migration tool.

Given you have a Flow system with your (outdated) package in place you should run the following before attempting to fix
anything by hand:

./flowcore:migrate--package-keyAcme.Demo

The package key is optional, if left out it will work on all packages it finds (except for library packages and packages
prefixed with “TYPO3.*” or “Neos.*”) - for the first run you might want to limit things a little to keep the overview,
though.

Collect all files from all packages (except Framework and
Libraries) or the package given with --package-key

For each migration and package

Check for clean git working copy (otherwise skip it)

Check if migration is needed (looks for Migration footers in commit
messages)

Apply migration and commit the changes

Afterwards you probably get a list of warnings and notes from the
migrations, check those to see if anything needs to be done manually.

Check the created commits and feel free to amend as needed, should
things be missing or wrong. The only thing you must keep in place from
the generated commits is the migration data in composer.json. It is
used to detect if a migration has been applied already, so if you drop
it, things might get out of hands in the future.