[Phpmyadmin-devel] 2.4.1 release schedule

[Garvin Hicking]

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.