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

[Ernesto Baschny]

Helmut Hummel schrieb am 27.05.2013 09:24:

> One thing I want to calrify. Is it really the intention to re-introduce
> int_from_ver into GeneralUtility like so: https://review.typo3.org/21047 ?
> 
> I think this would cause even more confusion which API to use.
> "Old" extensions used t3lib_div::int_from_ver, then had to use
> t3lib_utility_VersionNumber::convertVersionNumberToInteger.
> 
> With 6.0 t3lib_utility_VersionNumber was aliased to
> \TYPO3\CMS\Core\Utility\VersionNumberUtility and t3lib_div to
> \TYPO3\CMS\Core\Utility\GeneralUtility
> 
> This means in 6.0 you could use:
> 
> t3lib_div::int_from_ver()
> GeneralUtility::int_from_ver()
> 
> t3lib_utility_VersionNumber::convertVersionNumberToInteger
> VersionNumberUtility::convertVersionNumberToInteger
> 
> All doing the same.
> 
> But I assume nobody used GeneralUtility::int_from_ver() as this would
> only work in 6.0 and writes deprecation messages, so it does not make
> sense to do so.
> 
> In 6.1
> 
> t3lib_div::int_from_ver()
> GeneralUtility::int_from_ver()
> has been removed, breaking "old" extensions.
> 
> As much as I see the need to not break extensions during a migration
> from 4.5 to 6.2, I don't like to introduce
> GeneralUtility::int_from_ver() again, but instead an (optional)
> compatibility layer which provides this (and potentially other)
> method(s) to t3lib_div using inheritance instead of aliasing.

Conceptually this sounds like a good idea. Would be a clean solution at
the end.

> Find a rough prototype in my sandbox[1]
> [1]git cherry-pick origin/sandbox/helhum/t3lib_div-compatibility
> 
> There is a chicken/egg problem however, as I would like to have the
> t3lib_div alias in place early in the boot process if the compatibility
> extension is not installed. At this stage, it is however not (yet)
> possible to know if the extension is installed or not.

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.

> Nevertheless I think it is worth solving this problem instead of
> bringing back in_from_ver() to GeneralUtility as by that we virtually
> never can get rid of it.

"never" is not true, because we then simply delete it again in 6.3.
People have been warned enough already.

Extensions aiming for 6.3 (and later) compatibility will not care about
4.x/4.5 compatibility anymore. People will "branch" their extensions in
order to keep 4.x support separate from 6.x and later support.

6.2 is just "special" because many will be "just upgrading" to a new
generation code and their development team are not yet ready to cope
with branching extensions and supporting multiple branches at the same
time (but some will of course do so already). Not to speak of TER which
does not support branching of extensions just yet.

I'd like to hear more opinions on Helmut's solution, as it could be a
fundamental decision regarding these kind of decisions in future.

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