Let me first say I am happy with the progress of RoundCube and all
the work the developers are doing. However, as part of my plans to
migrate our servers to PHP5, I was wondering if there was any
information about the status of the migration of RoundCube to PHP5. I
remember that the devel-vnext branch was the target for this work,
but I might be mistaken.
Do the devs want to get out of RC stage to a 0.1 release before
concentrating on GoPHP5 ?
Should any patches be against devel-vnext instead of trunk ?
Should there be instructions on <http://trac.roundcube.net/wiki/
Dev_SVN> on how to check out and use devel-vnext ?
Is anyone using devel-vnext without major problems, known major
issues not resent in trunk ?
Am I asking too many questions ?
Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265
List info: http://lists.roundcube.net/dev/
On Jan 25, 2008 3:42 PM, chasd chasd@silveroaks.com wrote:
Let me first say I am happy with the progress of RoundCube and all the work the developers are doing. However, as part of my plans to migrate our servers to PHP5, I was wondering if there was any information about the status of the migration of RoundCube to PHP5. I remember that the devel-vnext branch was the target for this work, but I might be mistaken.
Not at all. We are working on merging.
But the current release works with PHP5 already. It may not be E_STRICT - but E_STRICT changes a lot anyway.
Do the devs want to get out of RC stage to a 0.1 release before concentrating on GoPHP5 ? Should any patches be against devel-vnext instead of trunk ? Should there be instructions on http://trac.roundcube.net/wiki/ Dev_SVN on how to check out and use devel-vnext ? Is anyone using devel-vnext without major problems, known major issues not resent in trunk ?
It's all bleeding edge - not too well tested currently since we moved around a lot of stuff last year. So I suggest you stick to 0.1-rc2 until we merged. We'll alert the list of anything that comes up.
Am I asking too many questions ?
No! ;-)
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
chasd wrote:
Do the devs want to get out of RC stage to a 0.1 release before
concentrating on GoPHP5 ?
Right. The 0.1 version will still run on PHP4 but right after the release we'll drop support for PHP4 in SVN and all upcoming releases.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
On Jan 28, 2008 12:52 PM, Thomas Bruederli roundcube@gmail.com wrote:
chasd wrote:
Do the devs want to get out of RC stage to a 0.1 release before concentrating on GoPHP5 ?
Right. The 0.1 version will still run on PHP4 but right after the release we'll drop support for PHP4 in SVN and all upcoming releases.
We are merging all changes from 0.1rc1, 0.1rc2 and trunk into devel-vnext right now. Tomasz comitted already a lot, and I am at it as I write this email (which is a contradiction in itself, but you know what I mean).
So how many more mergers of 0.1-versions do we need? I'd say we throw out a 0.1 ASAP then. :-)
Thoughts?
Cheers, Till _______________________________________________ List info: http://lists.roundcube.net/dev/
till wrote:
So how many more mergers of 0.1-versions do we need? I'd say we throw out a 0.1 ASAP then. :-)
I'd like to release 0.1-stable from the current trunk. Therefore we need to fix the open tickets assigned to that milestone.
After that, the merged devel-vnext can replace the trunk version if it works exactly the same as 0.1-stable. Test cases are required here!
The changes in devel-vnext are mostly code style plus a few new classes and auto-loading. If merging gets too complicated we could also copy the new things from devel-vnext one by the other into the current trunk and test continuously.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
On Jan 28, 2008 4:22 PM, Thomas Bruederli roundcube@gmail.com wrote:
till wrote:
So how many more mergers of 0.1-versions do we need? I'd say we throw out a 0.1 ASAP then. :-)
I'd like to release 0.1-stable from the current trunk. Therefore we need to fix the open tickets assigned to that milestone.
Ok, good to know. So I guess we finish the current merge and then focus on the important tickets in trac. :O
After that, the merged devel-vnext can replace the trunk version if it works exactly the same as 0.1-stable. Test cases are required here!
How are we gonna go about this? I was thinking of doing a couple Selenium tests for example, there is a Firefox extension to "record" them and then convert them to phpUnit. But how would we test the rest? Any ideas?
The changes in devel-vnext are mostly code style plus a few new classes and auto-loading. If merging gets too complicated we could also copy the new things from devel-vnext one by the other into the current trunk and test continuously.
I don't think it's so much easier the other way around. I believe there were a few more things, but anyway I think we are almost there. ;-)
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On Mon, 28 Jan 2008 15:53:11 +0100, till klimpong@gmail.com wrote:
On Jan 28, 2008 12:52 PM, Thomas Bruederli roundcube@gmail.com wrote:
chasd wrote:
Do the devs want to get out of RC stage to a 0.1 release before concentrating on GoPHP5 ?
Right. The 0.1 version will still run on PHP4 but right after the
release
we'll drop support for PHP4 in SVN and all upcoming releases.
We are merging all changes from 0.1rc1, 0.1rc2 and trunk into devel-vnext right now. Tomasz comitted already a lot, and I am at it as I write this email (which is a contradiction in itself, but you know what I mean).
So how many more mergers of 0.1-versions do we need? I'd say we throw out a 0.1 ASAP then. :-)
Thoughts?
Yes, I have one that might be of interest... Following is an announcement from the Author of the pecl-phar PHP extension I referenced in a thread related to saving all attachments in archived form. *** WARNING *** WARNING *** Windows users, beware, the Z word is used abundantly throughout the announcement. ;)
Announcement:
I have been working hard on pecl/phar to address several issues raised last May when it was first mentioned on the list, and would like to summarize where phar stands today with regards to those criticisms:
Criticisms:
- non-standard file format
- limited introspection
- no support for web-based applications
- by default, phar archives require the phar extension to run
- massive modification of php applications required to run them as a
phar archive
- no caching of phar files in opcode caches
- has write support in the extension
Current status of phar addresses most of these criticisms:
- full read/write support for tar and zip file formats plus original
phar file format
- introspection of phar-based archives is available via the "phar.phar"
command-line tool, and all standard tar/zip tools can introspect tar and zip files
- web-based phar archives has been completed, 1 line of code is needed
to enable the web front controller. Concept proved by running phpMyAdmin from its original tarball without code changes
- default stub for phar-based archives allows standard PHP applications
to run from a phar archive without the phar extension being present.
- interception of read-based file functions and include now allows most
php applications to run from a phar archive without any modification to the original code
- Gopal committed code to APC that allows caching of files from stream
wrappers
- write support is disabled by default, and can only be enabled on the
system level, this has not changed.
phar is also the first PHP extension to provide full read/write support of the tar file format on windows (libarchive supports this on unix) phar implements zip support with native PHP code, enabling some features not present in ext/zip such as opendir() stream support, bzip2 compression, file permissions stored in the zip archive, and greatly improved efficiency on accessing just a few files within a large zip archive. phar also supports creating and running gzipped/bzipped tar or phar archives without requiring decompression (this is done on the fly) at the expense of the expected performance hit.
Phar has no required dependencies, and optional dependencies on spl, zlib and bz2 (zlib+bz2 are obviously required for compressing/decompressing with those formats, spl is only required for fancy-pants stuff, the stream wrapper, web front controller, and other major features do not require spl)
Development is still actively occurring on phar, to fix a few known issues and increase code coverage in the unit tests. The enhancements above are in CVS in the soon-to-be-released phar 2.0.0.
If phar were in core, it would allow people distributing applications or libraries to bundle unpacking code or installation code inside the archive. Applications could also be designed to run right out of the phar archive for users to try them out or even for final installation using the standard tar/zip file formats. The phar file format has the advantage of not requiring the phar extension in order to run. The tar/zip file formats have the advantage that if the phar extension is not present a simple "unzip" command (or the equivalent for tar or for windows) allows easy installation.
As such, I would like to ask for a second consideration of bundling phar in core, as it has a huge potential for enhancing the distribution of PHP applications.
So it seems that it might now be even more worthwhile to consider support for this extension - possibly before the "big jump". /Especially/ given that it will be possible to distribute RC as a "phar" archive that can be run in a "demo" mode before commiting to an actual install!
Kewl, huh?
Well... you asked for thoughts. Didn't you? Now you have mine. :)
--Chris H
Cheers, Till _______________________________________________ List info: http://lists.roundcube.net/dev/
///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! .
List info: http://lists.roundcube.net/dev/
Chris,
On Jan 29, 2008 8:20 PM, chris# chris#@codewarehouse.net wrote:
(...) Well... you asked for thoughts. Didn't you? Now you have mine. :)
I appreciate the email but how is this relevant to my last email? I'm more looking for people to say, "I am gonna fix a bug". :-)
Thanks, Till _______________________________________________ List info: http://lists.roundcube.net/dev/
I just noticed in r968 the change to mdb2. While it certainly seems
the right direction to go, the mdb2 libs were removed from the svn 2
years ago. Will these be checked back into svn (for those not as
comfortable finding things on their own)?
I opted for the stable 2.4.1 version. Would this be the recommended
mdb2 version for roundcube? I'm certain the last version distributed
with RoundCube was older. I also wonder why mdb2 was removed. Anyone
know the reason?
Brian _______________________________________________ List info: http://lists.roundcube.net/dev/
I tested this yesterday and it did not work with default setting in config of mdb2. Needed to change back to db for svn trunk to work
From: "Brian Devendorf" developer@infointegrated.com Sent: Thursday, January 31, 2008 5:56 AM To: dev@lists.roundcube.net Subject: [RCD] MDB2 Checkin - Version / Include in Distribution?
I just noticed in r968 the change to mdb2. While it certainly seems the right direction to go, the mdb2 libs were removed from the svn 2 years ago. Will these be checked back into svn (for those not as comfortable finding things on their own)?
I opted for the stable 2.4.1 version. Would this be the recommended mdb2 version for roundcube? I'm certain the last version distributed with RoundCube was older. I also wonder why mdb2 was removed. Anyone know the reason?
Brian _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Someone had the problem on #roundcube too...
Maybe a test to switch back to db if MDB2 is not found will be usefull no ?
Regards,
On Sun, 3 Feb 2008 11:34:05 +0100, "Seansan" sheukels+rcdev@gmail.com wrote:
I tested this yesterday and it did not work with default setting in
config
of mdb2. Needed to change back to db for svn trunk to work
From: "Brian Devendorf" developer@infointegrated.com Sent: Thursday, January 31, 2008 5:56 AM To: dev@lists.roundcube.net Subject: [RCD] MDB2 Checkin - Version / Include in Distribution?
I just noticed in r968 the change to mdb2. While it certainly seems the right direction to go, the mdb2 libs were removed from the svn 2 years ago. Will these be checked back into svn (for those not as comfortable finding things on their own)?
I opted for the stable 2.4.1 version. Would this be the recommended mdb2 version for roundcube? I'm certain the last version distributed with RoundCube was older. I also wonder why mdb2 was removed. Anyone know the reason?
Brian _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
Hi,
On Feb 3, 2008 11:37 AM, Maximilien Cuony [ The_Glu ] maxi.the.glu@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Someone had the problem on #roundcube too...
Maybe a test to switch back to db if MDB2 is not found will be usefull no ?
The problem is that MDB2 is not bundled. I'll fix that ASAP.
Thanks, Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On Feb 3, 2008 12:34 PM, till klimpong@gmail.com wrote:
Hi,
On Feb 3, 2008 11:37 AM, Maximilien Cuony [ The_Glu ] maxi.the.glu@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Someone had the problem on #roundcube too...
Maybe a test to switch back to db if MDB2 is not found will be usefull no ?
The problem is that MDB2 is not bundled. I'll fix that ASAP.
Thanks to Sean for opening a ticket, just to let you guys know - MDB2 is now bundled.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
-
Brian Devendorf -
chasd -
chris# -
Maximilien Cuony -
Seansan -
Thomas Bruederli -
till