[TYPO3-core] New features and css_styled_content static templates?

[Ernesto Baschny [cron]]

Am 2013-08-28 13:50, schrieb Markus Klein:
>>
>> Hi Ernesto and Joey,
>>
>>> The compatibility static tempaltes are not meant to be "untouchable",
>>> their reason is to make the "rendering look the same as in an older
>>> version". So if we add new features, we could / should add them to the
>>> compatibility static templates also.
>>
>> OK, so I will add the necessary TS across all static template versions, for the
>> sake of completeness.
>>
>>> Although meanwhile after>7 years of having these compatibility
>>> templates I must confess that I've never used them, as usually we just
>>> want to move over and adapt the typoscript / css for the frontend
>>> while upgrading anyway.
>>
>> Neither do I, but they are still there. Actually it might be good to deprecated
>> the oldest ones (e.g. before 4.5), but we have no way of deprecating a static
>> template. Should we add one? It could be worth it, otherwise we will keep
>> accumulating static templates till the end of time.
> 
> I'd say we strip them all with the next version. Be it 6.3 or 7.0 as a "massive" breaking change.

As a policy I would propose that:

1) A static template is deprecated after two releases (like other APIs).
2) The static template from an LTS version stays until the next LTS.

Following this policy would mean that with 6.2 we would drop all static
templates: 3.x, 4.6, 4.7 and keep only: 4.5, 6.0, 6.1.

But since this policy is "new", we could start at the next release:

6.3 would only come with the templates from 6.1 and 6.2 LTS.
6.4 only with 6.2 LTS, 6.3
6.5 only with 6.2 LTS, 6.4
etc..

What do you think?

Some offtopic note while thinking about "where to document such a policy":

We don't yet have a central "Policies for Core Development" yet, maybe
there is the need for that. Francois, what do you think - where? Topics
I can think about could be:

- Deprecation Strategy
- General OS / PHP Version Support
- Rules about old CSC templates
- Rules about documenting rendering changes in compat_version for
Upgrade Wizard
- Policies (not "walk-throughs") around the Review System (Change-ID,
Topic, ...)
- Requirements of documentation for new features
- ...

Having such a central official document in my opinion makes it more
authorative than scattered throughout "tutorials" and "walkthroughs" and
"articles". A new contributor could read this one document and know all
the rules he need to follow.

Regards,
Ernesto