[TYPO3-ect] Ideas to clean up TER
Rens Admiraal
rens.admiraal at typo3.org
Sun Jan 29 12:31:19 CET 2012
Hi guys,
Just a few questions:
- If we want SVN / git as archive: do we also require extensions to be
in forge? And if so, doesn't it make sense to publish tags as extension
version in TER automatically? And by this requiring a solid tagging
workflow?
- What to do with extensions which are not in forge? It is now possible
to create a new forge project for an already published extensionkey...
- How can we help developers find the minimal / maximal required
version? Does it make sense to set the max version automatically to the
maximum version of the current release the developer uses to publish the
extension? For example: I upload an extension in 4.4, and the maximum
version is 4.3.99, It would make sense to set this to 4.4.99 during
publishing... (With some kind of user interaction of course)
- Does it make sense to create some automatic checks? You know for sure
an extension is not compatible with 4.7 if eregi() is used for example,
and the same can apply to certain core methods...
Just some thoughts ;-)
Regarding the other stuff in this discussion: I'd prefer not to delete
the extensions from TER, but hide them in some setting in the extension
manager. Like we had "only search reviewed extensions" before.
I've no real strong opinion on the extension keys policy, gonna follow
the people really into that :)
But I would like the notifications to developers when a new stable TYPO3
version is out, or the current maximum version is EOL. I can imagine
this is a trigger for developers to keep the extension maintained...
Greetz,
Rens
Op 29-01-12 11:27, Xavier Perseguers schreef:
> Hi,
>
>>> 1. the version constraints in em_conf.php will become mandatory (and
>>> cannot be higher than the current development version (a.k.a. "master"))
>>
>> So, this would be (as an example and simplified):
>>
>> $EM_CONF[$_EXTKEY] = array(
>> 'constraints' => array(
>> 'depends' => array(
>> 'typo3' => '4.5.0-4.6.999'
>> )
>> )
>> );
>>
>> Right?
>
> Yes.
>
>>> 2. once a TYPO3 core version becomes end of life the extensions which
>>> have that version as the upper limit will be removed from TER
>>
>> I am not 100% sure if *removing* these extensions is a perfect solution
>> to be honest: I came across situations in the past, where I needed an
>> old version of an extension... for specific clients' needs, for
>> analyzing, for my own learning purposes, etc. - even if the extension is
>> not maintained any more.
>>
>> I typical example would be that someone points to an extension/version
>> as a reply to a question in a forum or mailing list (e.g. "how can I
>> develop feature xyz? Answer: have a look at extension ABC, it does
>> exactly this.").
>>
>> Removing extensions from TER pro-actively (and automatically) would have
>> an impact on the "open source" and "inspire people to share" ideology in
>> my opinion.
>
> We have Forge SVN/git for accessing old versions or old extensions. I
> would not plan to prune those repositories so we should encourage people
> to share their work at the first place and host their extension on
> Forge. In addition, I'd be in favour of writing a good-practice tutorial
> (I can do that) on how to tag each extension version one sent to TER. In
> order to trace those versions within the SVN repository itself.
>
>>> - should authors be notified before a core version becomes EOL that
>>> their extension will be removed?
>
> Yes, that would be needed.
>
>> It would be a "nice-to-have" feature to inform extension developers in
>> two stages:
>>
>> (1) when a new stable TYPO3 version has been released that is *not*
>> listed in the em_conf.php array (this would motivate extension
>> developers to test their extension with the new release and update the
>> code if required)
>
> I'd say NO! There are already enough way of being advertised that a new
> version of TYPO3 is out (announcement mailing list and automatically
> updated feeds such as http://typo3.causal.ch/releases.php). There is
> enough time between a new major stable version and the EOL for people to
> have a chance to update their extensions before they'll be removed from TER.
>
>> (2) when the last TYPO3 version listed in em_conf.php reaches EOL
>
> Ideally.
>
>> Another question would be: does an extension get a new version every
>> time a developer updates the setting in em_conf.php? Even if there is no
>> code change at all?
>
> Exactly! There's nothing wrong with that! Just increase the last digit.
> It's exactly there for such changes.
>
>>> *) Removed as in: not available for download in TER.
>>
>> As described above... I do not have a problem if the EM would not list
>> "unmaintained" extensions and would not allow to download them from TER.
>> But I would suggest to keep/archive the code in the TER (still accessible).
>
> As said, I'd suggest to prune the TER altogether and rely on Forge for
> archiving extensions, perhaps moving them to some substructure within
> our huge SVN directory structure to "free" the extension key as well but
> that's another question.
>
> Kind regards
>
--
Rens Admiraal
Core Developer V5 Team
TYPO3 .... inspiring people to share!
Get involved: typo3.org
More information about the TYPO3-team-extension-coordination
mailing list