David.Comay at sun.com wrote: >> So, this is closer to being a precedent for PHP than I suspected, >> *IF* the intent is to support rolling upgrade within a Minor release >> (of Solaris) and to reset to a more current version at Minor release >> points. (Note 2005/462 above; we seem to be just getting around to >> this in Nevada.) Is this a match? > > Yes, that was the original intent of Stefan's proposal. > >> If so, the only thing missing is what are the criteria for >> introducing a new version of PHP5. Examination of the Perl case has >> this, and it doesn't transfer to PHP or anything else. I suspect >> these criteria will be specific for each versioned component we add >> to the system and will need to be supplied in each proposal. > > Agreed. In general, I think the criteria will be based on community > demand for an updated version, what features and/or fixes that new > version brings and obviously, what resources are available to bring > that new version forward. > > As the intent is to bring some semblance of stability here, I would not > expect that we would be integrating every version. :-) > > dsc So, could you update the spec with a paragraph or two to this effect? It would seem to lower the noise level here (who me?). It would probably be good to update it with whatever you decide to do with the links - I've tried to stay mostly out of that discussion until you'all nailed down a proposal.
It might be good to include in those paragraphs how you are like Perl and how you are not. I think one significant place you are not is that the potential for incompatible change is the rule rather than the exception. I think you also need to make it clear that [if] you intend to remove versions at Minor release points (like Perl). This goes against some of the asserted usage, but I think its critical as to how maintainable this is. - jek3
