Restructuring dependency checks in TER

How to go on with dependencies in extensions?

Current behaviour

  • On extension upload there is a check if the depends section in ext_emconf.php has typo3 and includes an actively maintained TYPO3 version
  • On a daily basis there is a check for all extensions in TER if they still support a actively maintained TYPO3 version

Definition of "actively maintained TYPO3 version"
The definition is based on the Release JSON (get.typo3.org/json).
Currently (since 2 days) these are v9 and v10.

Issue

Extensions with a dependency of v8 or earlier

Questions

  • Should we include ELTS versions (currently v7 and v8) into the definition of “actively maintained TYPO3 versions”?
  • Should we handle “outdated” extensions like this as well or will they keep outdated? If yes, you can upload extensions which are outdated on upload.
  • Should we narrow the dependency check down to “You have typo3 as dependency in your ext_emconf.php, you’re allowed to upload!”
  • How should we handle outdated extensions then?
  • You have another idea? Say it! :slight_smile:
  • Allow upload of extensions with only ELTS dependency
  • Disallow upload of extensions with only ELTS dependency
  • Extension versions with only ELTS dependency will be outdated
  • Extension versions with only ELTS dependency will not be outdated

0 voters

I’d suggest to allow ETLS versions because this allows to give a strong signal that ELTS is really supported when someone just as Dmitry is willing to keep up the support for his extension although typically useless in newer versions of TYPO3 (e.g., realurl) or simply because the extension author is not yet ready and up-to-date with his own websites and thus did not yet really care working on compatibility updates. Nevertheless, that’s good to have updates in TER as it shows the extension is still maintained.

It is likely that sooner or later the extension will be compatible with a more recent version of TYPO3 and that’s fine I’d say.

The risk of not being a bit flexible in that area (I wouldn’t remove any constraint and allow totally outdated extensions like only compatible with TYPO3 6.2), the risk is that extension authors refrain from uploading to TER and only release to packagist, which is already the case with some “current” extensions. That’s really a pity because the TER is the TYPO3 market place.

2 Likes

For me it sounds a bit crazy not allowing uploads for ELTS versions at all. If a ELTS / TER user reports an issue for an extension, the maintainer is not longer able to upload a fixed version. So I’m for adding the ELTS versions to actively maintained versions (which is true as long they are managed).

I think you misunderstood the current way of working. You can still upload extension supporting lower versions, but you must at least support at least one of the actively maintained.

So in other words: if you upload an extension compatible with 6, 7, 8 and 9, you are fine. If you do not support (yet) 9, you need to make it support 9 too.

I think this algorithm is good as it is now. There are just very little scenarios where you really do not want to support newer versions on purpose - I think we could flag certain extensions which make no sense in 9 anymore, as Thomas already exemplified with realurl. Those are exceptions to the rule, and maybe the authors need to explain personally why they need to be “whitelisted”.

One actual “problem” with the “blocking” of upload is that AFAIK TER only looks at the “latest upload” to consider which TYPO3 support is included. If you want to maintain separate versions for separate TYPO3 versions (i.e. my ext v1.x.x supports TYPO3 8 and v2.x.x supports TYPO3 9 and later), a new release of v1.x.x would be blocked even thou if there is a v2.x.x already supporting newer versions. If this is not the case, my mistake - and then its all fine with me!

1 Like

I don’t think lower versions should be blocked at all. I am uploading 1 version for each TYPO3 version for example (https://extensions.typo3.org/extension/cookieman/), the reason being purely to simplify testing.
I wouldn’t want to tell users (that were asking for v7 support which I politely declined btw) that TER does not allow me to upload anything for v8 any more. Don’t you think that would TER make look bad?

3 Likes

It’s blocking only releases which contains no “actively supported version”.

A release of an extension with dependency from v7 to v9 is not blocked, while a dependency to only v8 is currently blocked.

Ok, let’s take RealUrl again for example: that’s says Dmitry will not longer be able to pubish new bugfix releases, right? Doesn’t sound correct to me…

I just successfully uploaded https://extensions.typo3.org/extension/rtehtmlarea/ which has a v8 dependency

Yes, I added a hotfix yesterday to temporarily enable ELTS only releases.

2 Likes

i Think its a good Signal to “Mark ELTS” versions as outdated, and the paying customers, should know that they are behind. on their upgrades.

but extension authors should still be able to support and upload fixes for outdated extensions.
even an outdated extension might have a critical or security issue. and if the extension author is willing to provide a fix for this old version. it should be supported. even if its marked as outdated.

1 Like

So you would allow uploads even for TYPO3 6.1, 4.5, etc.?

Yes, I would.
It’s an edge case that won’t happen more than a handful of times and then so be it in my opinion.

It’s currently possible only for Security Team to upload versions for older TYPO3 versions.

The rationale when we introduced this constraint back then was to motivate extension developers to update their extensions to support latest TYPO3 releases as soon as possible.

It’s meant to solve the chicken/egg problem: a newer TYPO3 release is only as good as the amount of “common extensions” supporting it. Most users wait to upgrade when all extensions they depend on support the new version. Having this constraint in TER kind of pushes extension developers to keep up-to-date with the core.

So having said that, I would think upload policy should stay “as is”, with the following changes:

  1. maintain a list of exceptions where a new version does not make sense: realurl, rtehtmlarea etc.
  2. allow uploading an extension supporting only older TYPO3 versions, as long as any release of that extension already supports the latest supported TYPO3 versions. In that way extension authors could upload bugfixes to older branches (or even the security updates) - maybe this is already the case, I don’t know.

Security updates can be uploaded via the Security Team. Then the dependency check is disabled of course.