PCSpectra wrote:If he is selling COTS then a user-friendly installer should be included. In my experience (I've made this mistake twice now) having an user-friendly installer is critical. Remember many buyers are potentially acting as middlemen between their clients and you, and have no interest in reading a install.txt file
So if your only installation steps are to unzip the code, and go (no database or anything)... you should still have an installer that does absolutely nothing at all? I think not.
An install should be as much of a non-event as possible. If possible, no installation procedure at all is always optimal.
"COTs" is just a stupid buzz word. "off the shelf" software is a stupid concept. There is no such thing as "prescription" software is there? Selling software is selling software. If I write for a client once, who's to say I shouldn't also resell it as an "off the shelf" software too? Selling software is selling software to me. I try not to take on development work for stuff I can't resell anyways. It's only logical
If you want to include an installer that is one business strategy. Not including an installer is an equally valid business strategy (
consumer surplus).
So logically the answer to what should go in an installer, is as little as possible. Not because you are going to make the user perform manual steps, but because you shouldn't abuse the convenience of having that installer. You should just write forwards compatible code, as your first option. Only once the need arises, should you add to that installer, in my opinion. I don't think users like the fact Adobe's Creative Suite install takes hours to complete, for example.
The concept of an upgrade is distinct from an installer in my opinion. In my head when I think upgrade I think database migrations, which you don't even need an installation step for, technically. Just check the version on every request (ala Magento). If you already have an installer anyways, doing the database upgrades there could be more convenient.
So I guess the cliff notes of my position on this matter would be, that I feel strongly an installer for a PHP web application should not be doing much more then creating & upgrading the database schema. If your installer is copying files around, for example.. ala a desktop application's installer, you're doing it wrong. At most you should create a database, maybe set up some initial configuration in that database or on your filesystem.
The user should be able to install your web app in 5 seconds should the installer not work for whatever reason (permissions problem, password reset). I am telling you this from experience. A good percentage of users won't even find out how to chmod the file when the installer asks them too, so that's why its best not to have complex stuff in the installer in the first place.
For example, Magento diverted resources from their development to work on their "extensions" marketplace, which is a PEAR like package manager developers can use as an installer for their extensions. The only problem is Magento has all they can do to work on their main product, let alone a home brewed package manager, so it doesn't even let me charge for my code. Right off the bat now users can't use the Magento installer to install my extensions, since I charge. Due to this, I had to write my own installer to copy files around all over the place. Had they architect-ed the extension system in such a way that file copying was not required, they wouldn't have created an artificial problem for all their commercial developers like that. I'd love for my users to be able to unzip & go. Instead I have to sit and listen to them complain about the fact the installer didn't complete because of a permissions issue, or what not. When that happens though, theres only about 5 minutes of manual work for me, because I follow this philosophy of KISS (keep it simple stupid) for my installs.