[TYPO3-core] Bypass version compatibility check in 6.2 extension manager
xavier at typo3.org
Fri Nov 15 08:33:17 CET 2013
> Most extension developers are always behind with uploading extensions to
> TER. It would help if other users e.g. a TYPO3 admin could change the
> version settings of an extension in TER. This could be done after
> successful tests of that extension by several users.
For me there's a difference in the *current* situation of ownership and
information stored in TER which makes it not feasible to do.
> Then every user could see if a version of an extension runs under TYPO3
> 6.2. And the extension author could be informed by email and still
> continue his sleep.
This is specially something we want to prevent, the way dependency
constraints work is an easy way to force an extension author to be awake
at least once every about 6 months, see if its extension still runs
under the new version, fix if needed and upload a new version making it
clear that *the extension is still supported*.
This last point is crucial! If we would change the constraints on TER,
we would basically have a fork of the extension. Let's take an example,
I write extension X, compatible with 4.5 solely. At some point you test
it and report as a few other happy users that it works under 4.7, the
constraint is updated to reflect 4.5-4.7. But I still do not use 4.7
myself and cannot ensure it is actually the case. Fine you may think,
others tell you this is the case. Now, I create a new feature or do
something else, I still have only 4.5 at hand to test, and it might
break in 4.7...
The constraints an extension author is providing is a way to tell people
1) which versions have been tested but also 2) which versions (of TYPO3,
PHP, ...) are *supported*.
Now we have another important point. The Extension Coordination Team
decided together with other active contributors and RMs that TER should
only authorize extensions with valid range of *active* constraints to
TYPO3 to be uploaded (in short, you are not authorized to upload an
extension solely compatible with TYPO3 4.3, but you could upload an
extension compatible with 4.3-4.5 since 4.5 is still actively
supported). The rationale was that TER is a nice place to put one's
extension but we thought it comes at the price of forcing users to stay
a bit in sync with TYPO3 development. Otherwise we will never be able to
outdate old extensions. An outdated extension is not removed, it is only
hidden by default and may be visible again by uploading a new version
compatible with at least one actively maintained version of TYPO3.
However people at t3o decided to do it another way and kept the upper
limit test constraint but not the lower one, allowing anyone to still
upload updates for a totally outdated extensions making it "maintained
but outdated". Must say, I don't like it.
To go back to subject, we have a possible discrepancy between will of
extension author to support a newer (or older - e.g., realurl with PHP
5.2) version of TYPO3, PHP, extension X or Y and the fact that it may
actually "work". By preventing people from installing/loading such an
extension anyway, w/o taking constraints as a hard restriction, we do
not address real life scenario where reality is slightly different than
theory and perfect timeline. Not speaking (again) about upcoming
versions (-dev) where until beta1 there is *no* way to make a 3rd-party
officially compatible except switching from official TER release to the
git/svn repository, *when it is possible at all*.
Release Manager TYPO3 4.6
TYPO3 .... inspiring people to share!
Get involved: http://typo3.org
More information about the TYPO3-team-core