[Phpmyadmin-devel] 2.6.0-rc1

[Alexander M. Turek]

Hi there,

Marc Delisle wrote:
> 
> I vote for merging the new patch for a delayed 2.6.0-rc1. 
> First I was thinking that we are late in 2.6.0 cycle, but now I think:
> 
> - people that need mysqli already have 2.6.0-alpha1, or the 
> daily snapshot
> - for a 2.6.0 release, maybe it's important to have a new 
> look. Most users do not even have the server infrastructure 
> to benefit from our mysqli support, so the main thing they 
> will notice is the look :)

That's what I thought, too.

Michal Cihar wrote:
> 
> Maybe releasing aplha2 before we start new look merging?
> 

+1 from my side. We fixed some bugs and merged some smaller changes since
alpha1.

> There are tons of unneeded (and unwanted) changes like 
> removing echo "\n";, meging of more lines onto one and so on. 
> It needs huge cleanup...

Can you estimate how long this might take?

Garvin Hicking wrote:
> 
> I can live with that. You are right about people being able 
> to user 2.6.0, but alpha may sound way unstable to users, so 
> I was thinking that many will only migrate as soon as it 
> leaves the 'alpha' cycle.

Yes, but people who are afraid of alphas usually don't deal with MySQLi and
MySQL 4.1 either, do they?
MySQLi is a very yound php extension, bundled with php5 which is still beta
- just like MySQL 4.1.

When we started working on 2.6.0, we branched out 2.5.x because we expected
the development of 2.6.0 to take longer than usual.
As far as I know, there are no critical bugs that would require a fast
release and even if there was one: we could still merge a fix to the 2.5.x
branch.

The main features of 2.6.0 (MySQLi and full MySQL 4.1 / 5.0 support) affect
php and MySQL versions that should be handled at least as carefully as a
phpMyAdmin alpha version.

> As you maybe can see from my last work on PMA I'm getting a 
> new grip and time to spend on it. So if the patch will be 
> delivered in time I surely offer to work on it; just as 
> Michal said, we need to apply our coding style to the patch 
> and most of all try to maintain some backwards-compatibility 
> for the 'old' look.

What do you mean by "backwards-compatibility"?

> I was already thinking of splitting up the configuration file 
> into a ".design"
> php file where one could apply the many optical directives. 
> But doing so would mean huge work on the config_import utility...

No, it won't. Trust me. :-)

Regards,

-- 

Alexander M. Turek
<rabus at users.sourceforge.net>

       _           __  __          _       _           _
 _ __ | |__  _ __ |  \/  |_   _   / \   __| |_ __ ___ (_)_ __
| '_ \| '_ \| '_ \| |\/| | | | | / _ \ / _` | '_ ` _ \| | '_ \
| |_) | | | | |_) | |  | | |_| |/ ___ \ (_| | | | | | | | | | |
| .__/|_| |_| .__/|_|  |_|\__, /_/   \_\__,_|_| |_| |_|_|_| |_|
|_|         |_|           |___/ 
                                    <http://www.phpmyadmin.net>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3102 bytes
Desc: not available
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20040505/f73eee36/attachment.bin>