[TYPO3-core] RFC: #10043: removed deprecated functions

Ernesto Baschny [cron IT] ernst at cron-it.de
Fri Jan 2 17:46:52 CET 2009


Steffen Kamper wrote: on 02.01.2009 12:40:
> Hi,
> 
> here is a new patch without removal, but
> 
> * change openid to use _GP instead of GPvar
> * removed deprecate marks for $ICON_TYPES and t3lib_div::GParrayMerged

+1 from me too.

I would love to see your "Log of deprecated functions in TYPO3, trunk
version" organized a bit with more information about the effect of the
removals planned for 4.4 in a Wiki page. That would make it easier for
the 4.4 release manager at that future time to update NEWS.txt
accordingly (and do the "removal").

My idea from 16.10.2008 (typo3-dev list) again (Stucki promised to add
that to the core team guide):

Btw, do we have some "list" of stuff we want to deprecate when? The list
at http://wiki.typo3.org/index.php/Deprecated_features hasn't been
maintained for long. I think there should be a clear policy on how to
introduce "deprecations", just as we have when documenting Documentation
changes. My idea:

1) core developer touches some code and notices that he needed to add
some ugly "backwards compatibility" layer to keep older extensions or
sites happy.
2) He marks the "hack" as DEPRECATED (in the source code) and
3) Writes down the hack, the release version in the above mentioned wiki
page. Also on that page he notes when the backwards compatibility "hack"
will be deleted (2 major versions later, as we have agreed some years
ago) and how it will affect sites.

Before some major release (at alpha status, so that it can be tested),
the release manager goes through a list in the Wiki and kills all
deprecated stuff from the code (in one huge RFC). The wiki information
is then introduced into the NEWS.txt for all to know about it. The newly
stuff marked for deprecation will also be noticed in NEWS.txt, giving
site developers enough time to take care of it.

Cheers,
Ernesto


More information about the TYPO3-team-core mailing list