[TYPO3-core] "breaking" changes in minor releases?
Jigal van Hemert
jigal.van.hemert at typo3.org
Sun Jul 20 23:41:07 CEST 2014
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
> Here are two examples:
> 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.
> 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
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
More information about the TYPO3-team-core