[TYPO3-core] [TYPO3-core-internal] Deprecation strategy

[Christian Kuhn]

re-post to core list.


Hey,

On 07/08/2012 01:07 PM, Ingmar Schlecht wrote:
> As particular striking examples for very frequently used methods, I
> would name t3lib_div::intInRange() and t3lib_div::readLLXMLfile().
>
> Of course we need to keep code maintainable. However, I think the fact
> that TYPO3's core code is at some points rather hard to maintain is
> mainly due to the very complex parts like TCEMain / TCEForms or the FE
> bootstrapping (which is now improving), and not so much because of
> t3lib_div containing a few more methods than would be desirable.
>
> So, in short, I would be glad if we could consider the impact of such
> method removals and weigh it against the benefits.

I think deprecation, moving and removing is good and we need it. We can 
improve in communicating and tools helping to keep extensions 
up-to-date. We can also help administrators in a better way to decide 
which extension is a good choice to use and which should be omitted - 
for example with metrics in the TER.

One thing I'm worried about:
Our deprecation rule says 'Deprecate and remove after two versions'. 
This is a shorter time frame than our LTS strategy. We will probaly 
release a new LTS with 6.1 or 6.2. That means we can have deprecated 
things with 4.6 or 4.7 that are removed before next LTS. Currently, I 
see tons of sites running LTS 4.5 that will only upgrade to next LTS. If 
they do this upgrade in one step (which is a preferred way that we 
should explicitly take care of being smooth), the developers of local 
extensions won't even have a chance to see a deprecation, it will just 
fatal.

I've had the idea about an 'extension-scanner'. Goal is to run it on a 
eg. a current 4.5 instance and it tells you what needs to be done for a 
successful update to some other version. I think a lot of the bigger 
agencies would be interested in this, so maybe we could raise funds if 
we find a cool team to reach this goal.


Regards
Christian