The following PSARC cases discuss Perl. 1999/192 Perl Stephen Hahn closed approved fast-track 05/19/99 Mike Shapiro 2000/341 Perl Interface to libexacct Alan Burlison closed approved fast-track 04/24/02 Andrew Tucker 2001/145 Update of Perl Shipped with Solaris to V Alan Burlison closed approved fast-track 05/16/01 Andrew Tucker 2001/714 Removal of Perl 5.005_03 from Solaris 10 Alan Burlison closed approved fast-track 11/14/2001 Stephen Hahn 2003/072 Solaris AMP (Apache, MySQL and PHP/Perl/ Paul Cunningham closed withdrawn Terrence Miller/Andr 2003/661 Update Perl to version 5.8.x Alan Burlison closed approved fast-track 12/11/2003 Stephen Hahn 2004/010 Perl interfaces for Solaris Privileges a Casper Dik closed approved fast-track 01/14/2004 Gary Winiger 2005/462 Removal of Perl 5.6.1 from Solaris 11 Alan Burlison closed approved fast-track 08/03/2005 Stephen Hahn
(Ah, crazy tabs in my mailer again. Sigh. Why is this so hard?) The interesting one (IMHO) is 2001/145. Most of the mail log is an exchange between Alan and myself on pretty much the version and compatibility issues. Its as I remembered in that the issue was the binary module interface. However, I seemed to have made up anything about it ever being mis-classified. I must be confusing it with another case. The basic premise was to provide a rolling upgrade period between the Perl versions. The convience symbolic link was not updated until the next Minor release. The release schedule of Perl was asserted to be faster than (and asynchronous to) the release schedule of Solaris, but only by enough to result in a couple of versions of Perl on a given Solaris release. 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? 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. However, it may not be that simple. The Perl case is quite explicit that the "big number" or Major version is thought of as a language version and compatibility is very respected in the Perl community. Is this project team prepared to make that same claim for PHP? Perhaps a better way to express this is that Perl required the versioning for one interface among many and it was fairly easy to explain what that interface is and how to deal with its incompatibility. What are the set of such incompatible interfaces in the PHP stack and can we explain them to the user? I'm not sure what happens if the set of such interfaces is large or not easily enumerated. One view is that its simply not appropriate for integration into Solaris as anything more than Volatile. Other views are possible, but they move us further way from Perl being a precedent. Let's cross this bridge if we come to it. If you read 2001/145, you probably should ignore the details of the discussion about the differing semantics of our version scheme and those used by many communities. We have long since decided that we need to keep the communities numbers and just document that the user shouldn't assign the same properties to it as "native" Solaris version numbers. I also make a pejoritive remark about the differing semantics of even and odd numbered releases. I still think this is pretty lame (development vs. production should be a separate field, IMHO), but I really, really don't want to get into that debate here. - jek3
