Hi list,
-----Original Message----- From: Garvin Hicking
I also agree with Rabus about the new requirements of PHP and MySQL (after 2.5.0).
Looks like we have a deal on that issue? ;)
-----Original Message----- From: Robin H. Johnson § § +1 here as well, so I think it's a done deal.
Great!
Instead of talking about rc1, I should have said "feature freeze". We have to freeze someday :) So do we freeze on March 30?
I'm definitely positive about that. Only thing we could maybe put in the next release may be Rabus' installscript -- if he finishes that after his graduation. :)
My graduation is sometime in June, I bet you won't wait until then. ;-) The thing is, that I currently have some exams that are important for my A levels. The first one (Mathematics) was on last Thursday, the second one (Social Economics) today, the third one (English) next Wednesday and finally the fourth one (Physics) on April 1st. And after that, I'll probably have time for pma. Maybe earlier, maybe not. :-)
So, if we did the final feature freeze on April 6th, I'd probably make it. :-)
In this case, I'd propose the following:
- April 6th: Feature freeze - April 13th: 2.5.0-rc1 - April 27th: 2.5.0-rc2 (We probably need 2 RCs) - May 11th: 2.5.0 (if necessary 2.5.0-rc3) - May 18th: alternative release date for 2.5.0
About Sessions, I agree but I would prefer that the rewrite goes gradually into the tree, instead of a rewrite that stalls other developers. So we split the rewrite between developers?
You mean branching the project in "new features" and "session rewrite"? I don't know if it is possible to let multiple developers work concurrently on a session rewrite. What do you suggest there?
This is my suggestion:
After the release of 2.5.0, we rename all *.php3 files to *.php and create a 2.5.x branch. Rewriting all libraries for session support will probably take a little longer, so branching would be the best solution. The version number of the 2.5.x branch will be incremented to 2.5.1-dev, the HEAD one to 2.6.0-dev or 3.0.0-dev, whatever you want.
New features, like the session based stuff, go into HEAD, fixes into both branches.
About PHP3 and older MySQL, do we let the current workarounds in place? I say yes, would be a big job to remove them. But we no longer put workarounds for new debugging/features.
I vote for dropping older support. This will make the code smaller and easier to maintain.
§ Lets be careful about this. Some of the workarounds exist § literally as workarounds, but some of the other code (such as § my SQL parser) was written with PHP3 in mind, and if redone, § could radically benefit from pure PHP4.
I'd also vote for a combination of both: If you find a block that is obviously meant for php <= 4.1.0 only, drop it. But I don't think that we should search the code for passages that can be replaced by a foreach loop :-)
When doing the rewrite, we could perhaps think over several other aspects. Here are some things that came to my mind:
- OOP: Working with objects makes the code much more readable. I know that the OOP of php4 is primitive, but I also tend to use it sometimes.
- a library of abstract functions for most common MySQL operations. This would allow us to implement feature #572725 for instance. I know that this one has been rejected, but it won't be that hard to support other SQL dialects as long as we create seperate libraries for them as we do with the authentification modes. I don't want to go that far and support non-SQL DBS' either.
- Better variable and constant usage.
- A global bug catching mechanism, as we have already it in Robin's parser. I already wronte some functions for other projects that are dealing with this topic, perhaps I can port them to PMA.
I often think about such things before I fall asleep in the evenings, so perhaps I'll have some more ideas tomorrow. Be prepared! :-)
Regards,
Alexander M. Turek alex@bugfixes.info
+-----------------------------+ | The phpMyAdmin Project | | http://www.phpmyadmin.net | | rabus@users.sourceforge.net | +-----------------------------+ | [bugfixes.info] | | http://www.bugfixes.info | | rabus@bugfixes.info | +-----------------------------+