Hi,
Suggested schedule:
2003-03-23: ask translations on the list
2003-03-30: 2.4.1-RC1
Marc
Hi Marc!
2003-03-30: 2.4.1-RC1
I have some doubts if we should entitle this release 2.4.1. It's just that there are some bigger changes in the current release that may arise some problems, and people who adjust to the "*.1 is generally more stable than *.0 and we only rely on super-stable versions" rule may run into some trouble.
Falling under bigger changes, there are (in my opinion):
- The transformation system - Automatic PDF table layout - The "back button blows table creating" fix - The query window, query history - "Integrity" checks on the PMA_* tables when moving/deleting/creating tables - WHERE-Identifier highlighting - docSQL importer rework - Work on the Export-Layout and structure (auto-increment, inline comments, ...)
So I wonder if we should instead take some more days, name the release 2.5.0 and maybe - if finished then - include the "work in progress" installation script from Rabus. My first look at this script was great, so if this can be finished, it's a real big feature.
Concerning the current feature/bug set, I'd like to see some kind of fix for patch #701111 and maybe we also could get bug #649665, #703744, #615101 somehow to work correctly as suggested.
I hope I don't sound selfish if I vote for increasing the version numbering, because some of the new features come from my side. But I really don't feel them so totally stable that they should appear in a >.0 release for now.
Regards, Garvin.
Hi Marc, Garvin & list,
-----Original Message----- From: Garvin Hicking
2003-03-30: 2.4.1-RC1
March 30th is to early for a RC since the nomerous new features need a lot of debugging now. A beta would be OK for me.
I have some doubts if we should entitle this release 2.4.1. It's just that there are some bigger changes in the current release that may arise some problems, and people who adjust to the "*.1 is generally more stable than *.0 and we only rely on super-stable versions" rule may run into some trouble.
I fully agree.
Falling under bigger changes, there are (in my opinion):
- The transformation system
- Automatic PDF table layout
- The "back button blows table creating" fix
- The query window, query history
- "Integrity" checks on the PMA_* tables when
moving/deleting/creating tables
- WHERE-Identifier highlighting
- docSQL importer rework
- Work on the Export-Layout and structure (auto-increment,
inline comments, ...)
So I wonder if we should instead take some more days, name the release 2.5.0 and maybe - if finished then - include the "work in progress" installation script from Rabus. My first look at this script was great, so if this can be finished, it's a real big feature.
Garvin, my A levels have highest priorety at the moment. Unfortunately, I have various exams ("Vorabitur") until April 1st. I won't have much time during this period.
Furthermore, I have to tell you that my script is going to be PHP3 incompatible. I decided to go this way because the setup script is devided into several steps and I need sessions for passing information from one step to another. Imho, those few PHP3 users can still fill out their config file manually.
Concerning the current feature/bug set, I'd like to see some kind of fix for patch #701111 and maybe we also could get bug #649665, #703744, #615101 somehow to work correctly as suggested.
Bug #697979 (the one that patch #701111 tries to fix) is a good reason why we should use sessions throughout the application. I remember some other issues that were caused by too long URIs. We can only work around such problems as long as we support PHP3, but not fix them. I am really tired of coding workarounds against old versions. The php development is running towards 5.0 and we are still supporting relicts of the last millennium...
After the next release - whatever it will be named - we should think about phpMyAdmin's requirements. Currently we say:
- PHP3 >= 3.0.8 (released about 4 years ago) with MySQL extension or PHP4 - MySQL >= 3.21.0 (released about 6 years ago), but < 4.1.0
My suggestions:
- php >= 4.1.0 (Dec. 10th, 2001) php 4.1.0 introduced the superglobal arrays that make session management and accessing HTTP request variables as easy as it is now. This version is dated December 10th, 2001. I think, this is old enough.
- MySQL >= 3.23.32 (Jan. 22nd, 2001) MySQL 3.21.0 is more than 6 years old! Do we really need to support this relict? Even the MySQL manual says, "Version 3.21 is quite old now, and should be avoided if possible". The same for 3.22.x: This branch has already been marked as "discounted" by MySQL. MySQL 3.23.32 is the first MySQL 3.23 release that is marked a stable. Yesterday, I visited CeBIT in Hannover and talked to some MySQL guy about MySQL 4. He told me that the MySQL 4.1 binary distributions should be released this month. So with a little bit of luck and time - I don't know how deep I'll have to go into the code - we could support MySQL 4.1.0, soon. :-)
Before you refuse my suggestions, please note the following: It is not that PHP3 and MySQL 3.21 users suddenly aren't able to use phpMyAdmin anymore. There are still the old releases which are functional and stable enough. I cannot imagine, that a user being content with PHP3 an / or MySQL 3.23 wants to use phpMyAdmin's latest new features.
Furthermore, did anyone of you test phpMyAdmin 2.4.0 with PHP3 or MySQL 3.21? Is anyone of you able to do so?
Finally, please just have a look at our download statistics for 2.4.0: - php files: 76,065 downloads / 93.2 % - php3 files: 5,533 downloads / 6.8 &
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 | +-----------------------------+
Hi List!
My suggestions:
- php >= 4.1.0 (Dec. 10th, 2001)
- MySQL >= 3.23.32 (Jan. 22nd, 2001)
I fully agree to what Rabus said about PHP3/MySQL < 3.23 compatibility. I like the idea of leavin phpMyAdmin 2.5.0 the last release for older version compatibility. We should then try to implement MySQL 4.1 features and maybe some better InnoDB/Relationship as well as a complete Session-based rewrite of the code. Even though that sounds like much work I think adapting the current code to sessions should be more a work of some weeks rather than few months. And we basically need new code to make phpMyAdmin usable for future PHP/MySQL versions. Maybe some of you have read what I posted in the MS-SQL forum thread...
Anyways, those steps would then lead to a new phpMyAdmin 3.0. And most importantly as Rabus told, phpMyAdmin will always be in its previous version a tool for PHP3 users. Those people don't tend to be accessive to new feature implemented in phpMyAdmin if they won't even upgrade their PHP3 accounts. It's real hard to get a PHP3 server nowadays.
To make a long story short: +1 :-)
Regards, Garvin.
Garvin Hicking wrote:
Hi List!
My suggestions:
- php >= 4.1.0 (Dec. 10th, 2001)
- MySQL >= 3.23.32 (Jan. 22nd, 2001)
I fully agree to what Rabus said about PHP3/MySQL < 3.23 compatibility. I like the idea of leavin phpMyAdmin 2.5.0 the last release for older version compatibility. We should then try to implement MySQL 4.1 features and maybe some better InnoDB/Relationship as well as a complete Session-based rewrite of the code. Even though that sounds like much work I think adapting the current code to sessions should be more a work of some weeks rather than few months. And we basically need new code to make phpMyAdmin usable for future PHP/MySQL versions. Maybe some of you have read what I posted in the MS-SQL forum thread...
I also agree with Rabus about the new requirements of PHP and MySQL (after 2.5.0).
So the new version will be 2.5.0. Indeed I had mentionned this renaming to Garvin (or the list?) a few days ago.
Instead of talking about rc1, I should have said "feature freeze". We have to freeze someday :) So do we freeze on March 30?
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?
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.
Finally, phpMyAdmin 3.0 should be in a distinct branch, and the code would be .php based.
Marc
Anyways, those steps would then lead to a new phpMyAdmin 3.0. And most importantly as Rabus told, phpMyAdmin will always be in its previous version a tool for PHP3 users. Those people don't tend to be accessive to new feature implemented in phpMyAdmin if they won't even upgrade their PHP3 accounts. It's real hard to get a PHP3 server nowadays.
To make a long story short: +1 :-)
Regards, Garvin.
Hi Marc!
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? ;)
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. :)
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?
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.
Finally, phpMyAdmin 3.0 should be in a distinct branch, and the code would be .php based.
Yes, before beginning to work on session rewrite we should make a branch. If there are some major bugs in < 3.0 release, we should still be able to fix that independently.
Regards, Garvin.
On Mon, Mar 17, 2003 at 01:31:10PM +0100, Garvin Hicking wrote:
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? ;)
+1 here as well, so I think it's a done deal.
On seeing the impressive new feature list, I would like to extend a special thanks to Garvin. The amount of work he's put into this over the last little while is a sizeable contribution to PMA. Someday when I'm in Europe I'll buy you a beer!
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. :)
Agreed on the freeze date. My semester and final exams are over April 15th, so things get interesting after that ;-).
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?
I think that the session rewrite shouldn't be too intrusive if done properly. I've been playing around with a little idea for a session hack already that should be possible to drop into PMA. It's all based around knowing what values of variables get set where, and having a complete list of variables at each entry and exit point of the code.
However having two seperate branches, one for all other features, and one for the session rewrite may come in handy for working on it still
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.
Finally, phpMyAdmin 3.0 should be in a distinct branch, and the code would be .php based.
Yes, before beginning to work on session rewrite we should make a branch. If there are some major bugs in < 3.0 release, we should still be able to fix that independently.
In CVS terminology, I think PMA3 should be a new module 'phpMyAdmin3' rather than just a branch of the code. It should definetly be a full rewrite of PMA from the ground up, with additional consideration given to which PHP modules will be available in the PHP version we choose (4.xx).
This will enable us to keep the old 'phpMyAdmin' module intact in CVS as well for major bugfixes to it.
Anybody up for starting a wishlist for the proper re-write of PMA3 ? my initial requests: uses an HTML library (no raw HTML in the code) - MUCH cleaner easier to manage translations system - using gettext (see Horde) install script db-based config
Hi Robin!
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? ;)
+1 here as well, so I think it's a done deal.
Great. I'm really looking forward to the new abilities we're having with using more recent PHP/MySQL versions. :)
On seeing the impressive new feature list, I would like to extend a special thanks to Garvin. The amount of work he's put into this over the last little while is a sizeable contribution to PMA. Someday when I'm in Europe I'll buy you a beer!
Many thanks for that...that's making me blush. ;) Even though I think I haven't done too much special in comparison to all the effort you other guys put into this project, I really appreciate that. :-)
Agreed on the freeze date. My semester and final exams are over April 15th, so things get interesting after that ;-).
Maybe we all find a way to cooperate on the session-related rewrite off the code. :)
I think that the session rewrite shouldn't be too intrusive if done properly. I've been playing around with a little idea for a session hack already that should be possible to drop into PMA. It's all based around knowing what values of variables get set where, and having a complete list of variables at each entry and exit point of the code.
Yes, I thought of something similar. Kind of a drop-in-replacement for the grab-globals. There are mainly a bunch of major variable like $goto and all those input-hidden fields we have to take care of.
If I understand Rabus correctly, we should all immediately use $_POST and the like superglobals and $_SESSION[] = 'XXX' session storage. I wonder, how much data we are willing to store in a session. I guess we'd have an advantage if we store the whole configuration into the session and thus overriding a lot of configuration parsing?
On which kind of session propagating should we focus? Make cookie neccessary, rely on PHP's automatic session propagating, or include own functions to make sessions work no matter if session_trans_sid is enabled? I guess if we take over the SID propagation on our own, we'd be on the safer side...?
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.
Yes. I just had some "if PHPVERSION is >= 4000..." ... "else" construct in mind for PHP and MySQL, so we should drop all 'else' cases. Rework on critical workaround-functions should be applied were necessary.
In CVS terminology, I think PMA3 should be a new module 'phpMyAdmin3' rather than just a branch of the code. It should definetly be a full rewrite of PMA from the ground up, with additional consideration given to which PHP modules will be available in the PHP version we choose (4.xx).
You don't mean 'full rewrite' as in 'full rewrite', don't you? ;)
Anybody up for starting a wishlist for the proper re-write of PMA3 ?
I'm more willing to shed some tears on the extensive amount of work that would take.
uses an HTML library (no raw HTML in the code) - MUCH cleaner
If we use that, we should go with PEAR. Adapt with PEAR coding style, put PEAR error handling in it and we could ponder whether to user PEAR:DB or even better PEAR:MDB. If we make a complete rework, we should do it right. But, as I said before and on the forum - I don't see an early success for that. :)
Regards, Garvin.
Do we have any statistics as to what percent of sites are using an older version of PHP?
Brendan
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 | +-----------------------------+
Hi Rabus!
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
Fine for me.
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.
I also like that idea. The more I think about Robin's suggestion for a full rewrite, the less I'm motivated by it. I think we should smoothly expand the current sourcecode. First step would be to implement session usage where we want it to have. Definitely for propagation of the $goto and $sql_query, as well as the $language variable. Variables like $db and $table should be passed by GET/POST, so allow bookmarking and so on.
We should also use Sessions for authentication and for the config.inc parsing. I don't think we should put blob or mysql data into sessions, to maintain a multi-user environment and not being screwed when the table has changed and you still work with session representations of the table.
After we have gotten the sessions to work, we could get a grip on removing all those PHP3/MySQL 3.22 workarounds and maybe optimize some portions to PHP4 syntax/OO style, if useful. Maybe we can rewrite whole passages here, if necessary.
Then we should think about using and integrating a template class. We definitely need a powerful template classe (not the PHPLibs one) for many nested subsets and optional parsing of seperate blocks. Just think of the whole 'if $cfgRelation[xxxworks]' clauses where we have to create a seperate template block or even a whole new template file every time. I haven't got a look to Smarty, put it seems powerful.
When implementing the template system, we should CSS-cleanup the code. Remove style attributes and replace everything with classes. Maybe we find some other non-strict XML constructs which can be dropped as well.
After those three steps, we'll have a pretty lean application... let's do it. *g*
In the end of May I will be finished with my education, so I'll have more time after that and less the next two months. I hope I will be able to contribute a lot to this rewrite. Dropping the whole 'every time authentication and config.inc parsing and so forth' constructs should give us a pretty speed improvement. :-) (which may be completely wasted by using templates, BTW. :-( )
- 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.
I agree. We should really evaluate, if we can go with PEAR:DB or PEAR:MDB. XML-based storage could be great on MDB...
Regards, Garvin.
Rabus a écrit:
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
Hi all,
Are we feature frozen? :)
Marc
Hi Marc & list,
-----Original Message----- From: Marc Delisle
Are we feature frozen? :)
Unfortunately, I could not finish my setup script yet, but I almost have. Expect it tomorrow.
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 | +-----------------------------+
-
Ferguson -
Garvin Hicking -
Marc Delisle -
Marc Delisle
-
Rabus -
Robin H. Johnson