[TYPO3-core] Second Meeting for TYPO3 6.2 LTS Release

Kay Strobach typo3 at kay-strobach.de
Wed May 29 21:44:55 CEST 2013

Hello Jigal,

as we have the devIPMask and similar stuff - i suggest to have an
option, that deprecated functions break the core in dev context (even if
extdeval is installed).

The break down should be done with an exception stating the problem and
linking to a wiki article on how to solve the deprecation.
Additionally the exception message should state where the problem was
found (should be possible with the trace)...

Thanks for reading

Am 29.05.13 21:40, schrieb Jigal van Hemert:
> Hi,
> On 29-5-2013 19:57, Stefan Neufeind wrote:
>> But can't we make a separate MigrationUtility or something then that
>> people needing/wanting compat with 4.5 and 6.2 could switch to? It could
>> contain functions that behave the same way under both versions. Those
>> extensions would have a clear dependency on a migration-extension. And
>> once people are ready to drop 4.5-compat they could drop the need to
>> activate the migration-utility as well.
> People (including myself) are usually lazy. If there is a extension /
> module / utility that brings back the old stuff they will use it.
> Look what happens with deprecation: we deprecate a function with version
> X and announce that it will be removed with version X+2. After the
> release of X extensions are published that use the deprecated function.
> With X+1 the same happens and extensions from before X still use the
> function, because everything still works.
> X+2 is published and these extensions don't work. Now reports appear in
> lists that core X+2 breaks those extensions (not the other way around!).
> Weeks or months later a new version of these extensions is finally
> published that uses the new function.
> The compatibility stuff needs to stay until the end of the LTS and
> during that time some people might expect it to work with later versions
> of the core too.
>> The migration-part would just be there so that people don't need to /
>> don't dare to come up with their own compat-stuff.
> Therefore it would IMO be better if we publish this in an article or a
> series of articles. Extension authors could use what they need and be
> encouraged to at least understand what they are doing instead of
> blindingly relying on the magic in the compatibility classes.
> These articles could also point to newer alternatives for the old code.

http://www.kay-strobach.de - Open Source Rocks

TYPO3 .... inspiring people to share!
Get involved: http://typo3.org

Answer was useful - feel free to donate:
  - https://flattr.com/profile/kaystrobach

More information about the TYPO3-team-core mailing list