Many package maintainers need to decide when to upload a new version to Debian. Should the upload be done only after the official release, or is there a place for uploads during the development process. In the latter case there’s a need to balance between the benefit of early testing and feedback with the stability and not complitly breaking user’s environment (and package relationships) too often.
With the coming PHP 5.6.0 release, Debian kept being on the cutting edge. Thanks to Ondřej, the new version was available in experimental since alpha1 and in unstable/testing since beta3. Considering the timing of the PHP release related to the Debian freeze, I’m happy we started early, and did the transision to PHP 5.6 a few months ago.
But just following the development releases (betas ,RCs) isn’t enough. Both Ondřej and myself are part of the PHP community, and know the planned timelines, current status and what are the critical points. Such knowlege was very useful this week, when we new 5.6.0 was pending finale tagging before release (after RC4). This made take the report of Debiab bug #759381: “php5: TLS connections broken in 5.6.0 RC4″ seriously and contact the release managers.
First it was a “heads up” and then a real problem. After a quick disscussion (both private mails by me and on github by Ondřej), the relevant commit was reverted by the release managers (Julien Pauli & Ferenc Kovacs), and 5.6.0 was retagged. The issue will get more checks towrads 5.6.1 without any time pressure.
Although 5.6.0 isn’t production for anyone (yet), and like any major release can have issues, the close connectivty betweeen everyone saved compliants from the PHP users and ecosystem. I don’t emgine the issue been sorted so quickely 16 hours later. This is also due to the bug been reported on difference between two close release (regression in RC4 comparing to RC3).
To close the loop, if we’ve uploaded 5.6.0 only after the release, the report would be regression between 5.5.x and 5.6.0, which is obviously much harder to pinpoint. So, I’m not sure I have a good answer for the question in the begining of the post, but for this case our policy proved itself.