Le 12 mars 2012 à 15:00, Miroslav Lachman a écrit : > Jerry wrote: >> On Mon, 12 Mar 2012 13:19:40 +0100 >> Miroslav Lachman articulated: >> >>> I really understand that you don't have a time or will to maintain >>> more than 1 version of PHP - it is not an easy task. But what is the >>> difference between more versions of PHP in the ports tree and more >>> versions of Python, Perl, MySQL, Postgresql, Postfix... and many more >>> ports? There is always some reason why they are there. >>> Some of them (Perl 5.8 comes to my mind) are/were in the tree for a >>> long time after upstream EOL. >>> >>> Personally - I don't need older PHP versions for webaplications >>> written by my-self, but there are many hosted websites depending on >>> an older versions on our webhosting servers. Customers must wait for >>> update from their vedors etc. Even some mainstream Open Source CMS >>> and other applications lags behind PHP development. >> >> The primary reason that so many older/EOL'd versions of programs are >> still in existence is because by nature most individuals are just plain >> lazy. Face it, man only invented electricity because watching TV by >> candle light was not very convenient. >> >> Seriously though, all too many users have to be dragged into the future >> or else they will just rot in the past. If support for EOL'd crap was >> implemented immediately, support for the newer versions would be >> instituted lickety-split. > > It is not about EoL in the first place. PHP 5.3 is still maintained branch by > vendor. > And if we are talking about more than one branch... FreeBSD exists in 3 > parallel branches + HEAD.
Plus this way of thinking does not let place for inertia of big projects. Especially collaborative projects where you can have thousand of developers btw. You cannot ask all projects/piece of code to be ready to upgrade to new version at the same time, and I'm not speaking of projects that involve many other technologies than PHP. Some projects simply cannot follow the vendor versioning rate just because of inertia, just to say. Maybe this could also be a way to go here at some point, I cannot tell. Anyway I think that the steps of launching a new port/port usage/port deprecation is necessary for this exact reason. The other way would be to freeze all the tree from time to time (i.e. several months) and ask projects maintainers/developers to stick to each freeze. FreeBSD system do that, but in userland it is imho not possible due to the big amount of ports available, dependencies, conflicts, etc. But as I said, this is only my point of view, we will conform to any change since we have not enough ressources to handle or maintain a port like PHP. For the moment, I can say that this is not a lazy task when you have tens of servers to maintain, and this is why I started to post in this thread... > > 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" _______________________________________________ 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"
