John Plocher wrote: > Joseph Kowalski wrote: >>> I agree with Stefan that we will need three different versions, but for >>> different reasons: >>> >>> A) The latest and greatest >>> B) An arbitrary customer-selected historical version, and >>> C) A distro-selected version that is used by other components within >>> the distro. >>> >>> -John >> Could you say a little more about how you might see B) implemented >> appropriate to the available resources? Also, how does "customer >> selected" work? What are the options available to the customer? > > > The only things I would expect on the install media would be the > latest A and the distro-specific C. The other versions could be > made available for web download. If there was a web site that > maintained the set of older versions, any customer who had > standardized on an older version could find it and download it > from there. And the funding for this is coming from where? :-D
If we have money to throw at this, the absolutely right answer is to bribe the existing PHP community such that Solaris is a first tier supported platform. This can be done many ways, most of which are ethical and politically correct. I think the most successful way is to hire one of the significant PHP maintainers with the job description of "Just as it was, except you need to make Solaris a first tier platform". I'm serious about this. If lots of versions are required, lets not get into the business of being the middleman. I think customers would be happier too since it removes latency. I actually really wonder why we don't more often approach FOSS like we used to approach the ISVs - do something to make us important. For larger components it really is the better answer. If we need one for use of bundled components, we do what RedHat and others do - install one and stick with it. Anyway, unless somebody (David?) wants to assert that the kind of money to support websites with multiple versions (which we support just like the one on Solaris?) or hire a mole (openly), this seems not to be viable. Wish it was. It would truly be nice. >> What happens when a customer builds on A, a newer version, A', >> becomes available (which happens to be incompatable with A) and >> we update to A'? > > I presume that the "deployed customer" will mostly upgrade their systems > (rather than doing a fresh install). This implies that upgrade can't > remove A, or overwrite it with A'. Support love it when a system upgraded != a system installed (to this degree). I guess A would only have a versioned name. Any kind of genericly named link screws this up. A member of the frequent updater program would end up with quite a collection of these, but I guess that's only ugly and not a serious problem. > For the deployed user who wants to do a fresh install, there needs to be > a way for them to get and install their specific version (maybe via the > web as above). If all else fails, they could always install it off of > their old OS media. > > -John - jek3
