[Phpmyadmin-devel] 2.4.1 release schedule
rabus at bugfixes.info
Mon Mar 17 14:35:48 CET 2003
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? ;)
From: Robin H. Johnson
§ +1 here as well, so I think it's a done deal.
> > 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
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
So, if we did the final feature freeze on April 6th, I'd probably make
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
> > 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! :-)
Alexander M. Turek
<alex at bugfixes.info>
| The phpMyAdmin Project |
| http://www.phpmyadmin.net |
| rabus at users.sourceforge.net |
| [bugfixes.info] |
| http://www.bugfixes.info |
| rabus at bugfixes.info |
More information about the Developers