Hi,
the cvs version and Loic's version are forking more and more each day.
How many persons are testing Loic's version (LV)?
(You know I don't like code branching, so...)
Suggestion:
- we stop modifying cvs right now - we fully test LV - someone backports the changes made into cvs to LV - someone puts LV in cvs - we fully test cvs - this becomes rc4
Feedback?
Marc
Feedback?
How large is the difference between the LV and CVS versions? I strongly suggest that we consentrate on migrating the LV code into CVS so it's available to testing by everyone and then freezes the project (no new features - only bugfixes) until it's stable (tested by a RC4) and then released - and then we carry on with new features...
That's a bit annoying this way - but if we don't use branching in CVS then I think this might be the best way of doing things...
Other solution: freeze CVS and make the source ready for RC4 and get the final version on the streets - then migrating the LV code to a new release (2.3.0) instead...
But it depends on how much the LV code differs from the CVS code...
(and no, I'm unfortunately not testing the LV code, but is willing to do so if anyone would kindly mail it to me) ;o)))
Hi Geert,
The LV version is a rewrite, and also fixes some bugs. You can get it at
http://phpmyadmin.sourceforge.net/phpMyAdmin-loic-dev.tar.gz
Add my 2 patches (sent to the list).
Please test it. I will test deeply also, today, under Linux, PHP 4.0.6 and MySQL 3.23.38.
Other testers?
Marc
Geert Lund - SilverSoft Productions a écrit :
Feedback?
How large is the difference between the LV and CVS versions? I strongly suggest that we consentrate on migrating the LV code into CVS so it's available to testing by everyone and then freezes the project (no new features - only bugfixes) until it's stable (tested by a RC4) and then released - and then we carry on with new features...
That's a bit annoying this way - but if we don't use branching in CVS then I think this might be the best way of doing things...
Other solution: freeze CVS and make the source ready for RC4 and get the final version on the streets - then migrating the LV code to a new release (2.3.0) instead...
But it depends on how much the LV code differs from the CVS code...
(and no, I'm unfortunately not testing the LV code, but is willing to do so if anyone would kindly mail it to me) ;o)))
-- Kind regards Geert Lund
Hi,
Why we don't open a second cvs tree (like %devel)?
If we add more feature in the release, the final version is finish next year ;-)
Steve,
About final 2.2.0: I have mentionned in this list that I was in favor of releasing 2.2.0 with the quote bug, because this version has been tested more, and because people won't think we are approaching 2.2.0 if we have too many RC's.
But... Loic has worked a lot to produce his version, which (if the tests prove ok) will be better in the long run, and should solve the quote bug.
About the trees:
I got tired of maintaining 2 trees. However, I would be volunteer to backport the fixes made to current cvs since the LV fork, if we agree to - test deeply LV - freeze cvs for 2-3 days.
Marc
Steve Alberty a écrit :
Hi,
Why we don't open a second cvs tree (like %devel)?
If we add more feature in the release, the final version is finish next year ;-)
-- Steve
-----Original Message----- the cvs version and Loic's version are forking more and more each day.
How many persons are testing Loic's version (LV)?
(You know I don't like code branching, so...)
Suggestion:
- we stop modifying cvs right now
- we fully test LV
- someone backports the changes made into cvs to LV
- someone puts LV in cvs
- we fully test cvs
- this becomes rc4
I all,
I totaly agree with that :
- maintening 2 trees is not very simple... - add more feature in the release, and the final version is finish next year...
But i don't think that releasing 2.2.0 with the quote bug is a good idea too.
Well, however, this situation is not so critical.
I suggest that,
Step 1 :
- freeze new development (no new feature, only bug corrections) - test LV fork - merge LV fork and CVS - release RC4
Step 2 :
- standby (no new feature, only bug corrections) - release 2.2.0
Step 3 : - add news features... ... - add a 3D VRML/Flash view of database :)) - add an easter egg :pp ... - release 2.3.0 RC1
Oops, just another thing...(don't kill me :p)...I almost finished a new version of bookmark support (more effective with advenced auth). So, I keep it in a corner or should it be added in version 2.2.0 ? :p
Yours,
Armel.
Hi Marc,
okay, i agree your arguments, but every time we made the next release candidate (like 2.3.0 rc1, 2.4.0 rcX, ...) the real development in cvs stops, if we have no alternative cvs tree.
You can see the problem in the view of Loic's own phpMyAdmin version. Now we must test this version 'offline' ... and nobody can make real changes in the source.
Regrads,
Hi Steve,
I hope that the cvs freeze will be short ( a few days ).
I am not against having another tree, but after 2.2.0 is released.
I found that our old -devel tree was too much work to maintain, being almost identical to the normal cvs tree.
Marc
Steve Alberty a écrit :
Hi Marc,
okay, i agree your arguments, but every time we made the next release candidate (like 2.3.0 rc1, 2.4.0 rcX, ...) the real development in cvs stops, if we have no alternative cvs tree.
You can see the problem in the view of Loic's own phpMyAdmin version. Now we must test this version 'offline' ... and nobody can make real changes in the source.
okay, i agree your arguments, but every time we made the next release candidate (like 2.3.0 rc1, 2.4.0 rcX, ...) the real development in cvs stops, if we have no alternative cvs tree.
I agree - and it makes it a hell lot more difficult to trace changes and the influence of these changes to existing code. When involving many deveopers spread around the world - CVS becomes very essential to other developers in the spirit of checking code with changes made by other developers.
CVS is actually working as a developer-community and more important as a documentation of all minor/major changes - making it a lot easier to backtrace introduced bugs and resolving those.
So my conclusion: when developers ain't sitting around in the same office or building - CVS is essential to successfull development and bug-tracing/solving and it's really worth the trouble of maintaing "branches" - making it possible for everyone to see changes. So it's a bad idea to skip CVS and everyones staring to develop new features / making code more efficient in their own versions - making it a hell lot more dificult to merge all those versions in the end...
So let's keep the development visible to all in CVS and let it help in keeping the development-team together and focused on the same goal :-)))
-
Armel FAUVEAU -
Geert Lund - SilverSoft Productions -
Marc Delisle -
Steve Alberty