[TYPO3-core] RFC #14729: Backwards compatibility brocken by disabled deprecation log

[Ingo Renner]

Thomas Allmer wrote:

Hi Thomas,

> I see it like this: TYPO3 should work out of the box when installed. It
> should be as fast as possible and should not generate unneeded stuff.

I don't count the deprecation log as unneeded, in fact it's very important:
- for developers and admins to spot the usage of deprecated methods
- for us core developers and contributors to eventually clean up the 
core from old stuff

> Why generate a deprecated log if the admin using this TYPO3 version
> can't use it? maybe he doesn't have the knowledge or the time to look at
> it closely. I mean updating foreign extension is "hard" and won't help
> you anything if it's not published to the TER by its author.

It'll help the admins or other developers to provide extension 
developers with feedback on deprecated API usage.
This actually just happened to me: I was using deprecated APIs in an 
extension which I myself didn't notice, somebody else however did thanks 
to the deprecation log. I'm very thankful that he reported that to me so 
I could fix it and not let others run into a potential crash. Now if the 
deprecation log is off, how should I or anyone ever notice things like this?

> Why make it harder for regular admins? Most of them already struggle
> when installing TYPO3; why do they need to take care of disabling the
> deprecation log?

By introducing the status, we're actually making it easier as they now 
will be notified about it.

> As said before when installing it should work as good as it gets.

Right, this means no unexpected crashes that could have been avoided.

> For
> developers it's clearly great to have the deprecation log so they can
> get rid of deprecated functions, but I guess a lot of admins don't have
> the knowlege or the time to actually do that. The deprecation log
> doesn't help them at all it just makes TYPO3 for them slower.

It's not making TYPO3 slower when taken care of. Did you read the patch? 
There's a clear recommendation about disabling it in production 
environments. Nobody is recommending to have it activated there. When 
doing proper development you'll go from dev to testing to production, 
and it's important that people will spot possible errors early on during 
dev and test so that they do not crash in production.

> PS: it also can harm - just had a case where a too big deprecation log
> file crashed php all the time with fancy error messages. It was hard to
> track down and made me think why is it enabled by default?

See, that's why there's the status now, that will alert you way earlier. 
Since the introduction of the status report in 4.3, that should always 
be a first stop when there are problems with an installation.


In the end the whole discussion can be avoided and/or will be 
superfluous if we introduce contexts in 4.5. Contexts like dev, test, 
and production, so that things like the deprecation log are en/disabled 
automatically depending on the selected context.


Thanks for your comments, I appreciate that.


all the best
Ingo

-- 
Ingo Renner
TYPO3 Core Developer, Release Manager TYPO3 4.2