FreeBSD Port: php5-5.2.11_1 upgrade path to 5.3.0/1
in [Ports]
|
Prev: forcing ports to use Perl 5.8.8
Next: ports devel/pear
From: Doug Barton on 6 Nov 2009 12:41 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. :) 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. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Miroslav Lachman on 7 Nov 2009 07:32
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(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org" |