Hi, I would like to know if PHP 5.3.1 will fix the remanent big file (> 4GB) issue on 32bits system.
There was 2 patch posted to fix this, the first one was in bug #48886 and another one is there: http://www.php.net/~wez/lfs.diff<http://www.php.net/%7Ewez/lfs.diff> I don't know what is the expected protocol to get a patch examined, but I hope you dev will at least try them. I personnally have tried the one from bug #48886 and it's working as described (it's using php's double to return/handle filesize when it can't be stored in an 32bits int. As the integral part of a double is 52bits wide, this give way larger space for the filesize). I haven't tried the new one from wez, but the previous one didn't work. Hope it will get considered. Regards, X 2009/9/19 Pierre Joye <pierre....@gmail.com> > hi Johannes, > > It is a really great improvement that we don't have to worry anymore > about being in a release phase for a given branch. However one thing I > would like to improve in the merge frequency. Having a large merge the > day (or the day before) a RC does not sound too god to me. It would be > much safer to merge more often so we can valid them before the release > or point you to some missing bits if necessary. > > Thoughts&comments welcome, > > Cheers, > > 2009/9/4 Johannes Schlüter <johan...@php.net>: > > Hi, > > > > a new tool provides new opportunities and challenges, with the move to > > svn I took some of the new possibilities and after many discussions > > created a new release process which I'll try for 5.3.1 for which RC1 is > > about to be packed. (having trouble accessing the snaps box to build > > it...) > > > > The very short story for most devs is to go on and work on the branches > > as before (meaning trunk, PHP_5_3, PHP_5_2, commit at once etc.) > > > > The longer story is this: > > > > I've created a new branch PHP_5_3_1. This release branch receives > > selective merges by the RM (me) only! > > > > This branch will then be used to create RCs as often as needed > > containing these fixes, as we won't have snaps for this branch only svn > > checkouts and RCs will be available for testing. Therefore the aim is to > > provide stable RCs and the only change between the last RC and the > > stable release shall be the version number change. > > > > Once 5.3.1 is to be published the PHP_5_3_1 branch will be converted > > into a php_5_3_1 tag. (svn mv) And the 5.3.1 NEWS will be merged back > > into PHP_5_3. > > > > When committing to PHP_5_3 please be conservative till 5.3.1 is out to > > ease merging and testing (we have no snaps for PHP_5_3_1) and try to > > indicate whether you think the change should be merged or not and tell > > me if you think I missed to merge a commit. > > > > Once 5.3.1 is released this process will be reviewed and either be > > documented or modified. > > > > Hoping this works out, > > johannes > > > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > -- > Pierre > > http://blog.thepimp.net | http://www.libgd.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
