[TYPO3-core] change compatVersion=3.9.0 -> 4.0 in sysext/css_styled_content

Michael Stucki michael at typo3.org
Fri Mar 31 14:12:41 CEST 2006


As requested by Ernesto Baschny I am forwarding this mail from him:

===

As the "compatVersion" TypoScript condition check is currently only used
because of rendering changes added by me, I'd like to clarify some things:

The check was added (Sebastian Kurfürst) to be able for newer TYPO3
versions to "simulate" older behaviour in rendering output. This was
added mainly to provide a smoother UPGRADE path. This is not a "minimum
version requirement" check.

So there are three pieces of information involved:

1) the current running version of TYPO3.
2) the version the user wants to "simulate" (probably because he
upgraded from this older version) (the
"$TYPO3_CONF_VARS["SYS"]["compat_version"]" configuration variable).
3) the information in TypoScript about what changed in which version
(the "[compatVersion...]" condition).

In this particular case, we added some changes of rendering output of
css_styled_content (mailform-rendering) even before the release of
4.0beta1. The change was tagged in TypoScript with "3.9.0". So that if
one upgrades from 3.8.1, and wants to keep this compatibility mode, he
will get old behaviour (3.8.1 < 3.9.0). A fresh install of TYPO3 4.0-rc2
puts TYPO3 in "compat_version" of the current TYPO3 installation
("4.0-rc2" for example). The new behaviour will render.

Note that [compatVersion] is not really a "required-version" check, but
this is a side-effect of this setting! The condition tells us: "This
following TypoScript part will apply if the user has told us that he
wants output like version x.x.x". This naturally implies that the user
has at least "x.x.x" installed. It might be that the section enclosed by
such a condition uses features that are not available in previous TYPO3
versions. This is particularly important if extensions that are not
shipped with TYPO3 start using this condition.

With that in mind:

1) the [compatVersion] in TypoScript should reflect a moment in time
this change was added. So here it makes no sense to use "4" or "4.0",
but the full-blown-version number available ("4.0.0", or "4.0-rc1" or
whatever). As long as the compatVersion-function knows how to *order*
those version numbers, its ok (4.0-CVS makes no sense either, as we
cannot compare 4.0-CVS with say 4.0-rc1).

2) the "compat_version" in localconf.php should reflect:
a) the TYPO3-version which the user *originally* installed (this is done
by the "Install Tool").
b) the new current version after upgrading, but only after a
confirmation by the user (through the "Update Wizard").

So my conclusions:

1) we can keep [compatVersion] with an "=" operator (or better, if
possible, with no operator at all). Other suggestion: [compatVersionCheck].

2) we should not change the checks in css_styled_content/static/* to
"4.0.0", because anyone upgrading from beta, rc1, rc2 to "4.0.0" will
get back "old" behavior, as this don't reflect the timestamp when the
change was added.

Cheers,
Ernesto

Peter Niederlag wrote:

> Hi,
> 
> Type: Bugfix
> 
> BT reference: n/a
> 
> Description:
> sysext/css_stled_content/static/* use a condition [compatVersion=3.9.0]
> TYP03-Version was still set to 3-9-cvs when introducing the conditions
> so they needed to use something with 3.9. With TYPO3-Version now and
> finally being 4.0 this will cause some user-irritation.
> 
> Solution:
> I suggest to change the conditions to:
> [compatVersion=4.0]
> 
> attached patch fixes that for sysext/css_styled_content/static/*
> 
> Greets,
> Peter

-- 
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/



More information about the TYPO3-team-core mailing list