[TYPO3-v4] Minutes of the 9th meeting of the 4.7 Release Team

[Ernesto Baschny [cron IT]]

Hi,

Steffen Gebert schrieb am 30.01.2012 19:28:

>> Strategy for Handling of security releases
>> ===========================================
> 
>> * 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.
> 
> What happens to the issues in forge, which have been merged already and
> have the Target version of the security release set?

An idea would be to have "pseudo-versions" in Forge like:

4.5-next
4.6-next
4.7-next

And use these target versions instead for bug fixes *and* sec-fixes.

As soon as a release is done, the target version should be updated to
reflect in which release the fix was actually included (which can be
quite easily read here: http://www.typo3-anbieter.de/typo3-merges/).

Obviously (in my opinion) we shouldn't set "target versions" to bug
fixes at all while the fix is not ready, but history proves that it is
done. Usually by the Release Manager to specify some "must have" fixes
for the next release, but it has also been misused.

This above suggested scheme would minimize the constant need to update
the Target version if a fix is post-poned to the "next release".

> The whole process sounds like very much overhead.. but well.. for the
> sake of preventing regressions, it could really help. Looking forward to
> see, how good that works!

Yes, let's see. If it is all automated (as I expect it to be, else it
won't make sense), it will be pretty cool and very convenient to be able
to install a sec-fix release only and minimize the potential of a
regression in a running site until the next "bug fix release" is well
tested.

Cheers,
Ernesto