[TYPO3-core] Minutes of the 6.0 release team meeting

[Philipp Gampe]

Hi Jigal,

> How much performance is this going to cost?

It does autoload the classes, but nothing else.
As this is a build-in function, it should be really fast, because both names 
reference the same class.
Looking at the PHP source confirms, that the class is autoloaded and the 
alias is added to the class look up hash map. So it just uses up a few CPU 
cycles to create a new entry in the list of classes to point to the existing 
class.

>> I think by that compatibility is a much smaller issue. For extension
>> developers a webservice could be offerend that changes their extensions
>> to the new class names.

Or a source code update script like for FLOW3.

> Which basically means that we need separate versions of *all* extensions
> for 4.x and for 6.x? That's not going to happen.
> * most extension authors will not make updates until some time after
> things really break. In the mean time hardly anything is working. This
> means that if the original classes will be removed in 6.2, it basically
> means that any upgrade to 6.2 will be broken for many months.
> * TER and the IM are not capable of keeping both branches apart. It will
> suggest the latest version for 4.x too, which will not work

I am still in favor of separate extension repositories for the two major 
branches anyway.
But independent of that, the whole point of the alias stuff is to provide 
backwards compatibility.
If the performance penalty is not too bad, we can leave the compatibility 
layer in the whole v6 branch and only remove it together with v7.

But as Thomas already said, we will be going to deprecate the v4 series 
together with the release of v6.2.
v6.2 might even be the next LTS release, but this is something to discuss 
once v6.2 approaches.

Best regards
-- 
Philipp Gampe – PGP-Key 0AD96065 – TYPO3 UG Bonn/Köln
Documentation – linkvalidator
TYPO3 .... inspiring people to share!