Doug Barton wrote:
Miroslav Lachman wrote:
Even if there are just a "few" incompatibilities, it means some clients
applications on webhosting will stop working and clients will scream on
helpline right after the update of the servers PHP...
Sounds like you're familiar with the problems, why don't you volunteer
to maintain the 5.2.x set of ports after a fork? Now both problems are
solved. :)
I expected this answer :) And my answer is - I can try it. PHP with all
extensions is not the simplest way to start learning port maintaining,
but I can try it. The question is - are there committers willing to
commit it or is it something against some people opinion / against some
rules? (changes in Mk/bsd.php.mk will be needed)
And yes, I'm serious, assuming that there will be updates in the 5.2.x
series that users will need. If not, simply not updating their
existing ports is a reasonable solution.
It can be useful even if there will be no more updates - in case
somebody need to install new machine in to farm with older versions.
[until there will be next security hole in PHP 5.2 :)]
Seriously - if ports team is willing to have "legacy" versions in ports,
we need to discuss some rules for this work. Not just for PHP, but more
general. In which conditions we need/allow them, the naming conventions
(some ports already have more versions but names are not consistent,
some ports are using -dev, -devel, -current [3 different sufixes for the
development branch], Perl always uses p5- prefix, Python have py25-,
py26- etc.)
So is it better to renumber the legacy (forked) version to
php52-ext_name-5.2.12 leaving php5- line for 5.3 version or do it like
Python (py25, py26): php52- and php53-.
And wouldn't it be better to have for example PHP 5.3 in "devel" state
in ports for some evaluation period - earlier before PHP 5.3 will be
given as new 5.x main line so more people can test it even with limited
features, web developers can write/test own apps for PHP 5.3 etc.?
Availability of the devel version will give possibility to those that
want to play with new features accepting the risk and lighten the
pressure on maintainers to commit the new version to the main line.
Again - I can try to do the php52 port if it have sense.
Miroslav Lachman
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
