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

[Ernesto Baschny]

Helmut Hummel schrieb am 27.05.2013 18:17:
>> One potential solution would be to make the "compatibility" extension
>> simply required (and not unloadable). It's not that having it loaded
>> hits performance so there is no benefit not having it loaded.
>>
>> On the other hand we could also argue why have it in an extension anyway
>> if it is always loaded. We could simply add this compatibility layer to
>> the core. Only valid reason to have it separated as an extension would
>> be to have it's functionality enclosed in a place which can later be
>> deleted at once.
> 
> Every loaded extension has a performance impact. It might be low but it
> is there. Rather than making it required, I'd do some other kind of hack
> like requiring LocalConfiguration and looking into the Extension array,
> or look for a file that is generated by the extension. Something like
> that. I have not found anything that I find attractive enough to be
> integrated.
> 
>> "never" is not true, because we then simply delete it again in 6.3.
>> People have been warned enough already.

> This would mean to have a deprecation policy, where we can only remove
> old API after 2 LTS versions:

Woa no, you are putting words in my mouth. That's not what I meant. It
was meant specifically for this int_from_ver method.

> * 4.5LTS: No API code removal
> * 4.6 until 6.2LTS: only remove API that has been deprecated before 4.5
> * 6.3: Remove API that has been deprecated before 6.2
> 
> So API that has been deprecated in 4.3 or 4.3 can only be removed after
> 4.5LTS and 6.2LTS is released.
>
> We face a couple of problems here:
> 
> 1. We did not have this policy before, which means, tons of API is
> already removed from 6.1
> 
> 2. We cannot remove/ change API for nearly 8 years (which is virtually
> ages in terms of a web application)

Of course not, we will not put back methods that have been already
dropped in 4.6 .. 6.1 due to the existing deprecation strategy for no
reason and we don't need to change the deprecation policy which is well
known already for some years.

The origin of the "int_from_ver" decision came from me trying to get
attention to the fact that despite the deprecation policy, we also need
to think of the benefit of each actual deprecation.

I made the suggestion to bring back the t3lib/* stub files due to side
effects that are still not solved. Christian Kuhn immediately "vetoed"
this idea and I could agree to that. We need to find other solutions to
these problems as they appear.

But then Christian (who is the most prominent defender of "removing ugly
old code") was the one that brought int_from_ver into the talk and had
the idea to bring it back due to it's removal causing more pain than
benefits.

But this was a punctual decision - which is still not final due to the
current discussion here.


On a more "general" view: It doesn't mean we shouldn't get rid of old
methods at all in 6.2 LTS, but we should always consider what it means
to users compared to how the "deprecated methods" affects us as core
developers. We should judge individually by common sense.

There is the argument about "having to maintain old code". Well if it is
"so complicated" to maintain the old code, I would agree. But in case it
is a two line method. What is there to maintain?

Same argument about the code size: I agree we should reduce the amount
of "bloat" but again in this particular case: Four lines of code? That's
also why I am a bit skeptical of adding a "compatibility" extension and
a whole machinery just for these 4 lines of code.

Despite that there is being invested a huge amount of time in trying out
the compatibility solution - not considering the still required reviews,
potential bugs etc. I very much appreciate the dedication on that, but I
wonder if there aren't more important areas.

The argument of "forcing people to upgrade to newer API": That's a very
noble motive like "let's teach people a lesson on how to write good and
modern code" by first making it difficult to migrate. But at the end we
are not enhancing TYPO3 primary for educational reasons, but also for
much mundane reasons like "keeping my website running", "making people
trust the product", "minimize upgrade effort", "lowering barriers" for
everybody. That's why we still have class aliases for "old school" names
in place, and still do some fancy stuff to make sure people can safely
migrate. That's also so many professional people love TYPO3 because you
can upgrade your 10 year old installation to newest TYPO3 with very
little effort. That's incredible and is (still) a huge component of the
appeal TYPO3 has on professional agencies and companies using it.

The argument that we only need these hacks because "TER is not
supporting branches" yet is also irrelevant to the general question of
deprecation. Of course it would be cool if TER could manage "multiple
branches". But despite this, first there is "more in the world" than
just public extensions in TER. And second it's not just a matter of
being "able" to have branches, but sometimes it's just not possible to
do so (due to time / money / resource-constraints).

We have a huge user base (the 4.5 users) which is not yet used of us
really dropping deprecated APIs because we haven't done so actively
until 4.6. So this time the migration effort will very different than
has ever been before and I just want to make sure it's not getting more
complicated than needed.

Regards,
Ernesto

-- 
Ernesto Baschny
TYPO3 CMS Core Developer
Release Manager TYPO3 4.5 & 6.2 LTS

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