[TYPO3-core] Combining security and bugfix releases

[Ernesto Baschny [cron IT]]

Ernesto Baschny [cron IT] schrieb am 20.12.2011 02:20:

....

> In this particular sec-release we also have the problem that we need to
> publish a sec-release fast (because of the 0-day exploit in the wild).
> So basically we cannot "undo" the merges that have been commited to the
> branches since the last bug fixing release, so those will be included in
> the release. So currently:
> 
> - sec-release 0.x
> - regression discovered, release 0.x+1
> 
> Other workflow with a merge-freeze would mean:
> 
> - release bugfix 0.x
> - regression discovered, bugfix release 0.x+1
> - no further regressions, release sec-release 0.x+2
> 
> That is, one further release to push out, one further release for people
> to consider installing etc.
> 
> Other branching / git-techniques might help us to work out a different
> approach, but it won't help us with getting the fixes ready faster and
> it won't remove the potential of including regressions in any release
> (the danger of a regression in a sec-release is usually higher than on
> other bug fixes).

Just as an add-on resource I just stumbled over around this particular
topic, this is the discussion the Drupal gals and guys had some months
ago [1].

Basically they were also considering the "predictable releases" for the
7.x branch - once a month - and revisit the policy some months later if
they found out that there is no need for it anymore (e.g. not so many
bug fixes a month to make it worth it). In their case they use the "x"
in 7.x for their bug fix releases, and to me it seems that they mix bug
fixes and new features and change of APIs in these releases - which is
something we don't do.

There is also a note around security releases in the comments.

The sec team seemed to have established a policy since Drupal 6 of
releasing two sec-versions - one including only the sec-release, one
including the sec-release + all other bugfixes so far. An example from [3]:

- 7.4 was vulnerable
- on 27.7.2011 a 7.5 containing only the sec-fix was released
- on 27.7.2011 a 7.6 containing the sec-fix + all other pending fixes
- on 28.7.2011 (oops) a 7.7 containing the 7.6 release with the correct
version number :)

If we would consider this kind of approach, I would suggest the following:

- 4.5.x is considered vulnerable
- 4.5.x-sec1 is released with the sec fix only
- 4.5.x+1 is released with the sec fix PLUS all other pending bug fixes

People scared about potential regressions install the "x-sec1" release.
People wanting "cutting edge bug fixes" apply the "x+1" release.

For our GIT strategy, that would mean that we need to branch on specific
tags (to apply the sec-fixes), changes in the release scripts, ... etc!

What do you think?

Cheers,
Ernesto

[1] http://groups.drupal.org/node/150854
[2] http://drupal.org/node/1231510
[3] http://drupal.org/node/3060/release?api_version[]=103