We've upgraded our development environment, but I'm a bit apprehensive to upgrade the production server because of the new addition of composer and the fact that Fuel won't even load without composer. Is there any harm in uploading the composer.phar and composer.json files, running php composer update, and only then pulling in the branch that has upgraded to 1.6? Otherwise there will be a few seconds to a minute of "limbo" during which nothing would work because composer hasn't been installed.
In our case, our production servers don't have outgoing internet access at all, so running a git operation (to a github repository) or a composer update is out of the question.
So in our application repositories, we include all Fuel packages, the Fuel core, and all composer packages we need, so we can deploy to production without having to fetch additional code after deployment.
Upgrading the framework is part of our regular release cycle, it's not something we do separate. So the app will be in "limbo" anyway, since migrations need to run after deployment as part of the upgrade (our migrations do all upgrade jobs, not only DB changes).
As part of the deployment process, we change the virtual host document root to point to a landing page, and reload Apache to make that active. After the upgrade has finished and verified, it will be switched back to the application.
Ok, I didn't really realize how composer works - looks like if I installed it locally and added those files to the repo, I won't need to install it again on a different machine when I pull.
But thanks, I like that landing page idea. I was considering that but didn't think of just changing the document root.
The document root switch turned out to be the most easy solution. Any other would involve some part of the application (and the entire framework), which is exactly what you try to avoid when upgrading.
A different solution I've seen is to check in your index.php for some type of "switch" (for example existence of a file), and serve a static HTML landing page instead of calling the framework.
Technically this is ok, but it requires additional checks to be performed on every page request, which might be a performance hit.