After some more investigation, it *might* be related to a bug that existed in 4.0.7 with multiple levels of internal output buffering, so I may have spoken too soon. I can't really reproduce it, so I asked Yasuo Ohgaki to take a look at it. If it's indeed the issue, it's a one line fix that can be MFH'd today, and at any rate, it'll only affect people who use zlib.output_compression, plus the mbstring automatic conversion feature. Another option is that it may be a bug in the mbstring auto conversion, as there's at least one more bug report that may be related (#13698). It crashes under both HEAD and 4.1.0RC1 (HEAD requires a more complex script, but the bug is there).
Zeev At 16:57 10/11/2001, Zeev Suraski wrote: >Rasmus - whatever that issue is, it has not been fixed in HEAD. > >Zeev > >At 17:43 10/11/2001, Rasmus Lerdorf wrote: >>I think the assumption that the PHP_4_0_7 branch is "pretty stable" and >>"pretty much ready to go" is the key here. How do you know? I think it >>is up to the QA team to tell us if this is the case. From what I can see, >>I don't think this is so. >> >>Jani, did you ever resolve that issue you posted about on Oct.24 related >>to bug #13806? You said it was only reproducable in the branch but fine >>in HEAD at the time. >> >>-Rasmus >> >>On Sat, 10 Nov 2001, Zeev Suraski wrote: >> >> > Guys, >> > >> > We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on >> > which 4.1.0 is currently scheduled to be based on, has branched away a few >> > months ago. Some people have expressed concern that releasing 4.1.0 based >> > on that branch is not a good idea, because there have been so many changes >> > in the HEAD branch, and synchronizing fixes and so on is going to be a >> > headache. >> > >> > There are basically two options: >> > (a) Go with 4.1.0 based on 4.0.7 the way we originally >> > intended. Pros: It's pretty stable, tested, and pretty much ready to go >> > out the door with minimum extra work. Cons: We get a release out there >> > that is based on code from several months ago, which doesn't contain some >> > bug fixes and changes. >> > (b) Drop the current release branch. Rebranch from HEAD, and release >> 4.1.0 >> > based on the current CVS. Pros: All of the bug fixes/features go into >> > 4.1.0, we don't release a version based on old code. Cons: Requires a >> > complete new cycle of QA, as lots of key issues changed since we >> > branched. Two major examples that come to mind are the sessions code >> > (trans_sid) and file uploads, which were very significantly changed. >> > >> > My personal opinion is that we should go on with (a), and start the >> release >> > process for 4.2.0, based on the latest CVS, immediately afterwards. I >> fear >> > instability in the new sessions/file upload code too much, and don't want >> > to delay 4.1.0 for much longer. >> > >> > Thies, on the other hand, supports option (b), because he's afraid of >> > having a new release based on several months old CVS is going to be a >> headache. >> > >> > Your comments are quite welcome, let's try to reach consensus as soon >> as we >> > can (wishful thinking? :) >> > >> > Zeev >> > >> > >> > > > >-- >PHP Development Mailing List <http://www.php.net/> >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
