[TYPO3-core] "breaking" changes in minor releases?

[Jigal van Hemert]

Hi,

On 20-7-2014 18:47, Helmut Hummel wrote:
> How should we handle changes in minor releases, that fix bugs, but might
> also break third party code?

In general, no breaking changes unless it's a security fix.
For LTS versions it was important to keep stability. Clients chose LTS 
versions for stability and expect upgrades to not break existing 
installations.

> Here are two examples:
>
> https://review.typo3.org/31694
> This would break for users, that rely on the fact that all files from a
> specified directory are inlcuded, not only txt and ts files.

Not for 6.2 I would say. We really don't know what file extensions are 
used in the wild and it will break installations which use other file 
extensions. The argument (in gerrit) that backup files from editors 
would also be loaded is not valid IMO; it's the responsibility of the 
integrator/maintainer to keep the right files in those directories.

> https://review.typo3.org/20026
> This might break hooks/ XCLASSes, as a public property is removed

This is a harder case. The public property was "public" because it 
previously didn't have a visibility. There is a comment that it's 
internal and that the visibility had to be defined. Programmers could 
expect that it wouldn't be public in the near future.

> In the past we also had security fixes, which broke sites (sometimes
> heavily).

Here the choice is easier. If you ask clients which they prefer: an 
insecure site or the need to have someone do modifications almost 
everybody will prefer improved security.

> My proposal would be:
>
> Allow breaking changes for private API (second example) or "edge
> usecases" (third example; whou would expect .doc files to be included as
> TS?) or security fixes, but mark every such change as breaking ([!!!])
> in the commit message, no matter how small such breakage would be.

-1 (.doc files are not to be expected, but perhaps .typoscript, .inc, 
.ts3, .setup, .t-s, and a zillion other possibilities)

> By doing so, we could mor easily inform users about such changes and
> they can decide whether they might be affected or not before an update.

-- 
Jigal van Hemert
TYPO3 CMS Active Contributor

TYPO3 .... inspiring people to share!
Get involved: typo3.org