Maximum time for holding extension keys without upload

Current situation

Currently (22/04/18) we have 10,980 extension keys registered in the TYPO3 Extension Repository, having 3,506 extensions with no upload. So, 32% of all extension keys are reserved by their owners without using them. Since two years, every owner gets a notification about an extension key which is unused since one year. The owner has the possibility for 30 days to keep the extension key or release it to the community.

Discussion Topic

My suggestion: As an extension owner you have 3 months to upload a version for your extension key, otherwise the extension key will be removed and therefore released to be used by the community again.

Impact

  • No extension keys can be hold back any more
  • No ask for keeping unused extension keys

Possible Migrations

None

Pro

  • More free extension keys

Con

  • None

Organizational

Topic Initiator: Thomas Löffler

I don’t think it will optimize the usage of extension keys.
instead of reserved extension keys, which will be noticed only if you want to use this key, you will get dummy-extensions which will spam the TER.
and please consider: there are big (and slow) projects which may take longer than 3 months where you want to reserve the key before you go public.
In the end reserved extension keys are like reserved domains: it is a hassle but you have enough options to avoid the domain-/extension key-grabber.
And I think some extension keys are reserved in best intentions to give it to the community if they are needed. Just make it easily possible to contact the key owner.

3 Likes

I personally keep one extension key of a large extension, which is not given away for free, “reserved”. I would be the first candidate to push a dummy ext with a short Feature-Advertisement list - which will happen anyways sooner or later.

2 Likes

I would rather go after the other 60% of extensions and check which of them is still maintained. I would assume that at least 70% of them is garbage or outdated meanwhile.

Do you get complaints about extension keys not available? Or is it just because the amount of data that is stored? So my main question is: why do we need this?

I think releasing these keys is not the way to go. There are several developers that registers a key to make sure they have the possibility to release their extension in the future. So I think a better solution is to do the reminder every 6 months with the same “rules” like now, no reaction within 30 days = released. So ask the owner more often if he wants to keep the extension key.

Furthermore I won’t change anything. If I will lose my the keys I have registered but are not active for example, I know that those extensions we have will never be released in TER anymore because we will not refactor the extension to have another key.

1 Like

With the periodic reminder we already make sure that the owner of the key is still reading the email at the address that is registered and took the effort to confirm that the key should be kept.
Any further rules will only make people do more creative things. At first they will upload dummies (as others have noted), if the rules change to prevent dummies someone will come up with a service that periodically uploads functional dummies and so on.

If there is a shortage in possible extension keys we could take a look at the possibility to have unique vendor-key-combinations. Code wise it’s possible (at least in many places) to use the same key with a different vendor.That would also eliminate the need to reserve a key before the extension is published or to register keys for non-public extensions.

You will really quickly step on composer territory here. I would vote for no change, because I think a composer UI for the TER would be the way to go for the future anyway.
But this is just my opinion

3 Likes

Having namespaces for vendors would easily solve that.

3 Likes

I think nothing should be changed, unless there is a significant amount of complaints from users. And if that is the case, then instead of adding more rules, go the composer way and adopt their vendor prefixed name scheme.

3 Likes

I also think that something should be done on this topic if there are complains or there are problem with resources

  1. Don’t change it
  2. Introduce vendor namespaces.
2 Likes

This topic was automatically closed after 14 days. New replies are no longer allowed.