Yesterday I posted a call for testing to the ubuntu-server list:
There has been much work in Debian since wheezy was released, including a major transition to Apache 2.4[1]. The maintainers used this opportunity to overhaul the packaging, which also affected dependencies such as PHP[2].
Ubuntu has picked this up. We're now well into feature freeze, and expect to release in October with Apache 2.4 and PHP 5.5.
I have done some testing. Everything seems to work, but I am aware that users do quite radically different things with their Apache configurations.
So if you intend to use Apache and/or PHP in a future release, please take some time to check that your use cases still work on our current development release (Saucy).
If you have automated deployments and testing, then please adapt, run and test your deployments against the development release. This will put you in great shape for our upcoming LTS release next year.
It would be great to identify and fix any issues before release, when bugs are much easier to fix.
I know that there are many users who use Ubuntu Server as an easy platform on which to deploy a LAMP stack. It would be a shame if we broke something and were unaware of it. Both success and failure reports are appreciated.
A generally accepted key goal for best practice production use is an automated, reproducible and automatically tested deployment. Creating such an environment is a separate topic and out of the scope of this post. But if you're already doing this, or you intend to do this in the future, then I have a feature suggestion for you to note.
How about a branch that targets the Ubuntu development release? This way your continuous integration can flag any action you need to take to make your deployment work against the next release (and thus the next LTS, if you deploy on LTS). If we make a change that makes your life difficult, then you will be able to feed this information back to us, and we will be able to take this into account.
Bugs and design changes are particularly hard to fix after release, since we have to worry about not causing regressions for existing users. During development, this is not a concern. So doing this helps you too: more bugs get fixed quicker in time for the release that you want to use.
While I'm talking about continuous integration on deployments, it's
worth noting that it's worthwhile running your tests on the -proposed
branch of the stable release you're using, too. If you also test your
deployment with the -proposed pocket
enabled, then you can
detect and flag any failures on proposed stable updates before we
release them. If we know that a proposed update causes a regression in
your deployment, then we won't release it. To flag a proposed update as
causing a regression, just tag the bug with regression-proposed and
add an explanation. You can find the bug number from the affected
package's changelog in
/usr/share/doc/package/changelog.Debian.gz.