Hi all
moving this duscussion to list, because I thing it should be there :-)
Original message (Garvin Hicking, 19.11.2003 11:57):
a) Wait until after 2.5.5 RC1 and apply changes to HEAD then. Pro: No hurry for now. Con: I might not have the time then :)
No need to wait, if you have time :)
b) Branch off a QA_2_5_5 tree now, make the RC out from that branch and apply my changes to HEAD now. Pro: Work can start immediately, a quite stable 2.5.5 release. Con: Later PHP4-enabled release
We will say that we don't support php3, but the code will still contain many things for php3...
c) Branch of a PHP4_QA tree, apply my changes to that branch, merge the changes to HEAD later on. Pro: Agitate on a 'secure' branch, work can start immediately Con: Maybe harder to merge afterwards, less people testing it (because CVS snapshot is from HEAD, and people using CVS directly will most likely use HEAD as well).
People expect HEAD to be the currently developped one, changing this confuses them.
d) Make changes to HEAD. Make 2.5.5 the first PHP4-release, thus moving the 2.5.5 RC1 about 1-2 weeks later and having huge changes in that 2.5.5 release. Pro: Making a real worthy 2.5.5 release? Work can start immediately. Larger testing user base. Con: No 2.5.5 release with the latest features, moved schedule.
Good solution. If there are not any things that are worth of releasing quickly, I'd prefer this.
Michal Cihar a écrit:
Hi all
moving this duscussion to list, because I thing it should be there :-)
Original message (Garvin Hicking, 19.11.2003 11:57):
a) Wait until after 2.5.5 RC1 and apply changes to HEAD then. Pro: No hurry for now. Con: I might not have the time then :)
No need to wait, if you have time :)
b) Branch off a QA_2_5_5 tree now, make the RC out from that branch and apply my changes to HEAD now. Pro: Work can start immediately, a quite stable 2.5.5 release. Con: Later PHP4-enabled release
We will say that we don't support php3, but the code will still contain many things for php3...
c) Branch of a PHP4_QA tree, apply my changes to that branch, merge the changes to HEAD later on. Pro: Agitate on a 'secure' branch, work can start immediately Con: Maybe harder to merge afterwards, less people testing it (because CVS snapshot is from HEAD, and people using CVS directly will most likely use HEAD as well).
People expect HEAD to be the currently developped one, changing this confuses them.
d) Make changes to HEAD. Make 2.5.5 the first PHP4-release, thus moving the 2.5.5 RC1 about 1-2 weeks later and having huge changes in that 2.5.5 release. Pro: Making a real worthy 2.5.5 release? Work can start immediately. Larger testing user base. Con: No 2.5.5 release with the latest features, moved schedule.
Good solution. If there are not any things that are worth of releasing quickly, I'd prefer this.
I also prefer d). What about a reschedule of -rc1 to 2003-12-07?
Marc
Hi All
Who wants to make this function from libraries/sqlparser.lib.php PHP4-enhabled? As I'm not familar using strpos/strcomp and really don't know what the function is about, I don't want to screw that one up. :-)
-------------- function PMA_SQP_typeCheck($toCheck, $whatWeWant) { $typeSeperator = '_'; if(strcmp($whatWeWant, $toCheck) == 0) { return TRUE; } else { //if(strpos($whatWeWant, $typeSeperator) === FALSE) { // PHP3 compatible (works unless there is a real ff character) if(!strpos("\xff" . $whatWeWant, $typeSeperator)) { return strncmp($whatWeWant, $toCheck , strpos($toCheck, $typeSeperator)) == 0; } else { return FALSE; } } } ---------------
Regards, Garvin.
Hi
Original message (Garvin Hicking, 20.11.2003 15:59):
Who wants to make this function from libraries/sqlparser.lib.php PHP4-enhabled? As I'm not familar using strpos/strcomp and really don't know what the function is about, I don't want to screw that one up. :-)
I's quite simple :-)
function PMA_SQP_typeCheck($toCheck, $whatWeWant) { $typeSeperator = '_'; if(strcmp($whatWeWant, $toCheck) == 0) { return TRUE; } else {
Just uncomment this:
//if(strpos($whatWeWant, $typeSeperator) === FALSE) {
And remove these two lines:
// PHP3 compatible (works unless there is a real ffcharacter) if(!strpos("\xff" . $whatWeWant, $typeSeperator)) { return strncmp($whatWeWant, $toCheck , strpos($toCheck, $typeSeperator)) == 0; } else { return FALSE; } } }
Meybe it would be faster to store result of first strpos into variable and use it then in strncmp, but it depends what comsumes more time...
Hi All!
I also prefer d). What about a reschedule of -rc1 to 2003-12-07?
Alright then, since we can all agree on d) let's do it. 2003-12-07 seems okay for me, the changes should be done by then.
Rabus, if you want us to work together on this, we should split up the files and agree upon on what to change. It would be great if you could be reachable via ICQ/IRC tomorrow, when I will start working on that? If you're not there, I'll just start with it, and you can drop in later, right?
Regards, Garvin
Hi Michal!
moving this duscussion to list, because I thing it should be there :-)
I'm currently having huge trouble with the SourceForge Mailinglists, as they don't arrive at my usual mailaccount (they seem to just vaporize) and I have to route them through a freemail account, which is also not that reliable. Bottom line is, I hope that my message arrives and I get all your replies. :-)
No need to wait, if you have time :)
Yes, there is a larger project in sight, but not yet approved. But it may get approved in the middle/end of next week, and I'd have the time to dig into the files now. :)
I'm really looking forward to this, as once the code is leaner, we may get basic Session-support easier to work, to get rid of those nasty redirects once and for all.
d) Make changes to HEAD. Make 2.5.5 the first PHP4-release, thus moving the 2.5.5 RC1 about 1-2 weeks later and having huge changes in that 2.5.5 release. Pro: Making a real worthy 2.5.5 release? Work can start immediately. Larger testing user base. Con: No 2.5.5 release with the latest features, moved schedule.
Good solution. If there are not any things that are worth of releasing quickly, I'd prefer this.
This version would be fine for me. I currently have nothing left in the queue for 2.5.5 (apart from the above mentioned ;-)...
Regards, Garvin.
-
Garvin Hicking -
Garvin Hicking -
Marc Delisle -
Michal Cihar