[TYPO3-v4] Dropping the compat_version

[Ernesto Baschny [cron IT]]

Steffen Gebert schrieb am 23.10.2011 20:40:

> what do you think of dropping the compat_version setting?
> 
> Does it make sense anywhere to behave like the such a beloved $MS
> product, which imitates to be its predecessor?
> 
> At least I would say that we do not care about this setting since ages,
> so I think we should remove it for *4.7*. (without deprecation).
> 
> (as we just stumbled over a bug which was caused by a misunderstanding
> of the compat_version setting).
> 
> Looking forward to your feedback!

A little history about this:

We introduced this setting in the install tool back in 4.0 when we
started modifying the frontend output of css_styled_content, at that
time introducing css styled text with images. We didn't want "old sites"
to break because of the upgrade (so upgrading from 3.8 to 4.0 provided
no breaking change in the frontend). Admins had to specifically enable
the new rendering by rising compat_version setting (during the Upgrade
Wizard - which was also introduced at that time).

Technically the solution was having tons of TS-conditions in the
css_styled_content setup.txt to cope with the different variants of our
FE-rendering.

Some years later (for 4.3) it turned out ugly to maintain these tons of
conditions, so we split up the different variants of
css_styled_content's setup.txt in "per version" files [1], so that no
conditions are needed, and the admin can just choose the "one he likes"
(i.e. to make the FE behave like 3.8, 4.2, or "cutting edge").

Another use was to "change defaults" between versions, for example in
4.1 we made config.inlineStyle2TempFile and minifyJS default to "1" (was
0 before) and removeDefaultJS=external (was empty before).

Nowadays (5 years after its introduction) the compat_version switch is
barely used (in the core).

It also turned out to be ugly to have only one "central switch" for this
compatibility setting, because the more we use it, the less benefit the
admin has from it. It is not always an "all or nothing" decision: people
want to test new features but still have the benefit of backwards
compatibility "here and there".

For us developers it is of course a "pain" to maintain old legacy code
which is deprecated anyway, and we can be proud that we still render
"old school 4.0 FE-style" in the latest 4.5 product, but this is not a
"must have" in my eyes - anymore.

One last situation which might also happen are extensions *and* site
implementations (TypoScript) which behave differently based on
compat_version: This is probably not that wide-spread, but might happen.

So +1 on deprecating this feature and removing it according to our
release strategy (deprecating it NOW and removing it 2 versions later).

But be aware that, as soon as we do this, we have to be change our
"backwards compatibility" policy for the frontend rendering. Either we
"drop it", or we accept breaking changes, if they are clearly documented
somehow (maybe by providing TypoSript snippets to "re-enable" old style,
for example in case of changed defaults). The Core Team has still to
deal responsibly with breaking changes, because the smooth upgrade path
is one of the fundamental aspects that sets us apart from competing
products.

Cheers,
Ernesto

[1] http://bugs.typo3.org/view.php?id=10320