9th Release Team Meeting TYPO3 4.7

The 4.7 release team meets weekly for a Skype discussion round on the current activities.
If you find this report interesting or have some comment or question about a particular topic, don't hesitate to follow-up on the thread in the v4 mailing list.

On Monday, January 23nd 2012 we hold our 9th meeting with the following participants:

  • Steffen Ritter (4.7 Release Manager)
  • Xavier Perseguers (4.6 Release Manager)
  • Oliver Hader (Core Team Leader)

TYPO3 4.7

Nothing special has been discussed about TYPO3 4.7.

Merging Mailinglists

The release team discussed the merge of typo3.dev, typo3.core and typo3.projects.v4 due to low traffic and cross-cutting concerns.
We decided to ask the core team about their feeling regarding thes question.

Strategy for Handling of security releases

Since in the past some security releases had introduced regressions the release team took the time to discuss a new strategy of dealing them:

postulated requirements

  • everyone planning to install a security release already upgraded to the latest patch-level release
  • the latest patch-level release does not contain regressions

We considere these points as as granted as soon as 1 month passed, since the latest patch-level release has been published.

facts and procedures

  • New security releases should not be combined Bugfix/Security releases anymore.
    Therefore they won't be based upon the head of the branch (for example TYPO3_4-6) but based upon the tag of the latest patch-level release since the branch may already have new bugfixes included.
  • security patches are applied within the hidden security-repository to a branch, based on the latest patch-level-tag.
  • a new variant of our release script automatically will create a new version from the latest tag, applying the patches within that "tag-branch" of the security repository.

Handling of regressions in security releases

  • Regressions in security issues are fixed within the hidden security-branch the release has been created from
    Regression fixes are considered to be security fixes, too.
  • the new release script variant will be re-run and again create a security-release based upon the latest "stable" patch-level tag and the current fixes in the security branch - this time including the fixes to the regression.

Bugfix release after a security release

For the next "normal" release security fixes are applied to the HEAD of the version branch on release. This should happen 2 or 3 weeks after the security release when we can be sure, that have not have been regressions.