On 09/26/2011 01:50 AM, Kumara Guru wrote: > Fair enough, but I am not a person they would/could share details > with. If someone could provide the data, that will be helpful.
Unless you have talked to *anyone* handling a large deployment, all you can do is speculate about their needs which isn't useful. Not many people will explain the specifics for you in a public mailing list. Deployment use cases and requirements are often treated as confidential. > I've explained it before. I am not asking you to upgrade your setup > whenever, say, PHP had a new point release. I am asking you to upgrade > when a major shift happens This is precisely what a release supported for a long time with a conservative update cycle lets you do. Upgrade on your convenience. Virtualization, cloud computing etc can be useful but enterprises are conservative by nature typically and not necessarily interesting in trying out something new to solve their old problems, be it a new version of a software or a entirely different technology. Some of them are leaders and invest heavily in technology but this is probably less than 10%. "Does having problems stop them from providing a new version?" Not necessarily but it isn't a trivial problem to solve. Look how long it takes for people to move over to PHP 5. This means, supporting releases of PHP for your customers. Add to that, rest of the stack and combinations thereof and you begin to understand the complexity. Often, FOSS software don't care much if at all about backward compatibility or ABI stability with very few exceptions. This is part of the problem that leads to a demand for a single release to be supported for a long time. Rahul _______________________________________________ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
