[TYPO3-core] Strategy for deprecation log

[Markus Klein]

Hi!

> 
> Am 03.04.2013 10:35, schrieb Patrick Broens:
> > Hi,
> >
> >>> I would like to have some more informations with the pure entry:
> >>> last occurence,
> >>> first occurence,
> >>> number of occurences
> >>
> >> Just out of curiosity: Why do you need that information?
> >> In my experience, all I ever needed was:
> >> - Which deprecated methods is called
> >> - Where is it called
> >
> > I was thinking the same. Although I can imagine it might be useful
> > when the modification time of the file is changed by touching it each
> > time the deprecated method is called from a certain place. Then you
> > know this warning is still relevant in time or not.
> >
> so all deprecations should be recolved it might give a hint which deprecatiosn
> should be solved first, as they occur more often.
> 
> otherwise this information may be relevant to check against times of
> updates, installation, deinstalltion
> 
> the information of "deprecation has occured last 5 month ago" gives no hint,
> wether the deprecation has been solved or wether it occurs only very
> seldom. This may be deduced from number and time intervall.
No matter how often a deprecated call occurs, in the currently suggested patch, each log entry is contained only once.
Even if you have 30 lines in the log file, you'd have quite a good overview of what's going on.
No need IMO to having timing information. There's no deprecation that is more or less critical.
Any deprecated method is old code, therefore the calls to it have to be removed!

> 
> and BTW:
> we may have filters which deprecations should be ignored:
How do you think the detection should work? Shall we parse the backttrace??

> 
> for everyone not involved in coredeveleopment a deprecation warnings
> from the core are irrelevant as they will be resolved with a comming core-
> update.
IMHO there should be a rule for RMs that releasing a version with deprecation warnings from Core should be forbidden.
(Core shouldn't break its own rules)
Hence, this point is not relevant anymore.

> 
> deprecations from foreign extensions which are maintained, but not
> updated each week can be ignored, as an update is not my work and
> propably will come anyway.
> 
> 
> bernd
> --

Kind regards
Markus Klein