Stefan Teleman wrote:
> Joseph Kowalski wrote:
>
>> 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?
>
> Question:
>
> If we remove the following symlinks:
>
> /usr/bin/php -> /usr/php5/[version]/bin/php
> /usr/lib/libphp5.so -> /usr/php5/[version]/lib/libphp5.so.x.y.z
> /etc/php5/php.ini -> /usr/php5/[version]/etc/php.ini
>
> and we only have
>
> /usr/php5/[version]/{bin,lib,modules,share,include,etc}
>
> would this alleviate the concerns about stability level and commitments ?
>
> i do not believe that the user expectation about php being in the
> default path is similar to the expectation about perl or gcc (for
> example).
>
> --Stefan
Maybe not "alleviate", but certainly simplify the discussions.
We certainly still need to figure out the appropriate commitment to the
versioned path and when [version]s can be added or removed.
In any case, I think we are best ignoring the "generic names" for the
moment. Let's resolve the hard question (about how the versions are to
be managed) and then look to see if a generic name makes sense in that
context.
- jek3
