I've started working on the framework. The list of backward compatibity breaks will be long. Here's the first part.
Renamed functions:
rcube_imap::decode_address_list() > rcube_mime::decode_address_list() rcube_imap::decode_mime_string() > rcube_mime::decode_mime_string() rcube_imap::decode_header() > rcube_mime::decode_header() rcube_imap::mime_decode() > rcube_mime::decode() rcube_imap::explode_header_string() > rcube_mime::explode_header_string() rcube_imap::unfold_flowed() > rcube_mime::unfold_flowed() rcube_imap::format_flowed() > rcube_mime::format_flowed()
Removed functions:
rcube_imap::select_mailbox() rcube_imap::in_searchset() rcube_imap::id2uid()
Hi Alec,
I strongly suggest to create a development branch for this work.
~Thomas
A.L.E.C wrote:
I've started working on the framework. The list of backward compatibity breaks will be long. Here's the first part.
Renamed functions:
rcube_imap::decode_address_list() > rcube_mime::decode_address_list() rcube_imap::decode_mime_string() > rcube_mime::decode_mime_string() rcube_imap::decode_header() > rcube_mime::decode_header() rcube_imap::mime_decode() > rcube_mime::decode() rcube_imap::explode_header_string() > rcube_mime::explode_header_string() rcube_imap::unfold_flowed() > rcube_mime::unfold_flowed() rcube_imap::format_flowed() > rcube_mime::format_flowed()
Removed functions:
rcube_imap::select_mailbox() rcube_imap::in_searchset() rcube_imap::id2uid()
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 05.01.2012 13:08, Thomas Bruederli wrote:
Hi Alec,
I strongly suggest to create a development branch for this work.
Right. However, I want to do "storage" releated changes in trunk and the whole rest in a separate branch.
On Thu, Jan 5, 2012 at 1:19 PM, A.L.E.C alec@alec.pl wrote:
On 05.01.2012 13:08, Thomas Bruederli wrote:
Hi Alec,
I strongly suggest to create a development branch for this work.
Right. However, I want to do "storage" releated changes in trunk and the whole rest in a separate branch.
I didn't add anything before – sorry, I'm late with this email. But the proposed changes all make sense and creating a framework to allow others to re-use our code sounds really exciting! :)
Do you guys have any thoughts on going all the way with 5.3+?
Till
List info: http://lists.roundcube.net/dev/ BT/aba52c80
till wrote:
Do you guys have any thoughts on going all the way with 5.3+?
That would, of course, be desirable from a developers perspective but remembering all the complaints when moving to 5.2 as a minimum requirement I guess it's to early. Hosting companies and linux distributors seem to lag behind the ongoing development and still have 5.2 in their repositories. PHP 5.4 is still not released stable and until that we should at least support one major version more than just the most recent one.
~Thomas
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 2012-01-06 15:36, Thomas Bruederli wrote:
till wrote:
Do you guys have any thoughts on going all the way with 5.3+?
That would, of course, be desirable from a developers perspective but remembering all the complaints when moving to 5.2 as a minimum requirement I guess it's to early. Hosting companies and linux distributors seem to lag behind the ongoing development and still have 5.2 in their repositories. PHP 5.4 is still not released stable and until that we should at least support one major version more than just the most recent one.
as both a hoster and programmer myself, i completely agree with you.
on the hosting side, it will still take some time for a php 5.2 to php 5.3 transition because
(a) there are still supported distros with php 5.2 (think: never touch a running system) and
(b) there are plenty of customers, ignorant to software updates, who are still running non php 5.3 compatible appplications (e.g. joomla 1.5) or custom code which makes a (forced) transition even harder ...
(of course, you can run php 5.2 and php 5.3 side by side but that increases maintenance efforts)
so +1 for keeping 5.2 compatibility a little longer.
cheers, raoul
Thanks Raoul, you're taking the words out of my mouth :D Being a hoster I see the same problematics with the migration 5.2->5.3. Big problem as example: Zend Optimizer to Zend Guard Loader. Completely different and encoded apps won't be working anymore. That's some huge bugger for a hoster. So +1 from me as well to stay 5.2 compliant.
On Fri, Jan 6, 2012 at 6:42 PM, Raoul Bhatia [IPAX] r.bhatia@ipax.atwrote:
On 2012-01-06 15:36, Thomas Bruederli wrote:
till wrote:
Do you guys have any thoughts on going all the way with 5.3+?
That would, of course, be desirable from a developers perspective but remembering all the complaints when moving to 5.2 as a minimum
requirement
I guess it's to early. Hosting companies and linux distributors seem to
lag
behind the ongoing development and still have 5.2 in their repositories. PHP 5.4 is still not released stable and until that we should at least support one major version more than just the most recent one.
as both a hoster and programmer myself, i completely agree with you.
on the hosting side, it will still take some time for a php 5.2 to php 5.3 transition because
(a) there are still supported distros with php 5.2 (think: never touch a running system) and
(b) there are plenty of customers, ignorant to software updates, who are still running non php 5.3 compatible appplications (e.g. joomla 1.5) or custom code which makes a (forced) transition even harder ...
(of course, you can run php 5.2 and php 5.3 side by side but that increases maintenance efforts)
so +1 for keeping 5.2 compatibility a little longer.
cheers, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia@ipax.at Technischer Leiter
IPAX - Aloy Bhatia Hava OG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office@ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/e21360c6
List info: http://lists.roundcube.net/dev/ BT/aba52c80
Ok,
I guess those are all valid points. I think as long as we keep the versioning sane and don't race to a 1.0 too quickly we can always change the requirement when more people came around to 5.3. I am hoping this is more sooner than later. With PHP 5.4 around the corner, there are a lot of benefits to upgrading.
I'm not aware of the Zend Encoder/Zend Guard specifics. I'll see if I can dig up something from Zend to learn more about it.
Till
On Fri, Jan 6, 2012 at 7:26 PM, Claudio Kuenzler ck@claudiokuenzler.comwrote:
Thanks Raoul, you're taking the words out of my mouth :D Being a hoster I see the same problematics with the migration 5.2->5.3. Big problem as example: Zend Optimizer to Zend Guard Loader. Completely different and encoded apps won't be working anymore. That's some huge bugger for a hoster. So +1 from me as well to stay 5.2 compliant.
On Fri, Jan 6, 2012 at 6:42 PM, Raoul Bhatia [IPAX] r.bhatia@ipax.atwrote:
On 2012-01-06 15:36, Thomas Bruederli wrote:
till wrote:
Do you guys have any thoughts on going all the way with 5.3+?
That would, of course, be desirable from a developers perspective but remembering all the complaints when moving to 5.2 as a minimum
requirement
I guess it's to early. Hosting companies and linux distributors seem to
lag
behind the ongoing development and still have 5.2 in their repositories. PHP 5.4 is still not released stable and until that we should at least support one major version more than just the most recent one.
as both a hoster and programmer myself, i completely agree with you.
on the hosting side, it will still take some time for a php 5.2 to php 5.3 transition because
(a) there are still supported distros with php 5.2 (think: never touch a running system) and
(b) there are plenty of customers, ignorant to software updates, who are still running non php 5.3 compatible appplications (e.g. joomla 1.5) or custom code which makes a (forced) transition even harder ...
(of course, you can run php 5.2 and php 5.3 side by side but that increases maintenance efforts)
so +1 for keeping 5.2 compatibility a little longer.
cheers, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia@ipax.at Technischer Leiter
IPAX - Aloy Bhatia Hava OG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office@ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/e21360c6
List info: http://lists.roundcube.net/dev/ BT/aba52c80
Hi,
In r5764 changes required in the plugins for the new Roundcube Framework were put into the trunk version of the plugins. Please consider using a separate branch for the plugin work, just like for the changes in the core so that the plugins will continue to work with the current Roundcube trunk in the meantime.
Thanks,
Phil
From: dev-bounces+roundcube=tehinterweb.co.uk@lists.roundcube.net [mailto:dev-bounces+roundcube=tehinterweb.co.uk@lists.roundcube.net] On Behalf Of till Sent: 07 January 2012 16:48 To: Claudio Kuenzler Cc: RoundCube Dev Subject: Re: [RCD] Roundcube Framework and BC breaks list
Ok,
I guess those are all valid points. I think as long as we keep the versioning sane and don't race to a 1.0 too quickly we can always change the requirement when more people came around to 5.3. I am hoping this is more sooner than later. With PHP 5.4 around the corner, there are a lot of benefits to upgrading.
I'm not aware of the Zend Encoder/Zend Guard specifics. I'll see if I can dig up something from Zend to learn more about it.
Till
On Fri, Jan 6, 2012 at 7:26 PM, Claudio Kuenzler ck@claudiokuenzler.com wrote:
Thanks Raoul, you're taking the words out of my mouth :D Being a hoster I see the same problematics with the migration 5.2->5.3. Big problem as example: Zend Optimizer to Zend Guard Loader. Completely different and encoded apps won't be working anymore. That's some huge bugger for a hoster. So +1 from me as well to stay 5.2 compliant.
On Fri, Jan 6, 2012 at 6:42 PM, Raoul Bhatia [IPAX] r.bhatia@ipax.at wrote:
On 2012-01-06 15 tel:2012-01-06%2015 :36, Thomas Bruederli wrote:
till wrote:
Do you guys have any thoughts on going all the way with 5.3+?
That would, of course, be desirable from a developers perspective but remembering all the complaints when moving to 5.2 as a minimum requirement I guess it's to early. Hosting companies and linux distributors seem to
lag
behind the ongoing development and still have 5.2 in their repositories. PHP 5.4 is still not released stable and until that we should at least support one major version more than just the most recent one.
as both a hoster and programmer myself, i completely agree with you.
on the hosting side, it will still take some time for a php 5.2 to php 5.3 transition because
(a) there are still supported distros with php 5.2 (think: never touch a running system) and
(b) there are plenty of customers, ignorant to software updates, who are still running non php 5.3 compatible appplications (e.g. joomla 1.5) or custom code which makes a (forced) transition even harder ...
(of course, you can run php 5.2 and php 5.3 side by side but that increases maintenance efforts)
so +1 for keeping 5.2 compatibility a little longer.
cheers, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia@ipax.at Technischer Leiter
IPAX - Aloy Bhatia Hava OG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office@ipax.at 1190 Wien tel. +43 1 3670030 tel:%2B43%201%203670030 FN 277995t HG Wien fax. +43 1 3670030 15 tel:%2B43%201%203670030%2015 ____________________________________________________________________
List info: http://lists.roundcube.net/dev/
BT/e21360c6
List info: http://lists.roundcube.net/dev/ BT/aba52c80
Phil Weir wrote:
Hi,
In r5764 changes required in the plugins for the new Roundcube Framework were put into the trunk version of the plugins. Please consider using a separate branch for the plugin work, just like for the changes in the core so that the plugins will continue to work with the current Roundcube trunk in the meantime.
That was an accident. The changes from the development branch are now merged back into trunk and the codebase should be consistent again.
Please note that trunk *can* be broken at any time. During development things might remain broken for some days.
~Thomas
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 05.01.2012 12:26, A.L.E.C wrote:
I've started working on the framework. The list of backward compatibity breaks will be long. Here's the first part.
And more:
Removed globals $DB, $USER, $IMAP Added abstract class rcube_storage, a parent for rcube_imap class
Deprecated rcmail methods: imap_init() > storage_init() or get_storage() imap_connect() > storage_connect()
Renamed storage (rcube_imap) methods: set_default_mailboxes > set_default_folders set_mailbox > set_folder get_mailbox_name > get_folder mailbox_status > folder_status get_mailbox_size > folder_size list_mailboxes > list_folders_subscribed list_unsubscribed > list_folders create_mailbox > create_folder rename_mailbox > rename_folder delete_mailbox > delete_folder mailbox_exists > folder_exists mailbox_namespace > folder_namespace mod_mailbox > mod_folder mailbox_attributes > folder_attributes mailbox_data > folder_data mailbox_info > folder_info mailbox_sync > folder_sync expunge > expunge_folder clear_mailbox > clear_folder get_headers > get_message_headers list_headers > list_messages messagecount > count message_index > index message_index_direct > index_direct
Removed storage (rcube_imap) methods: reconnect get_response_str
A.L.E.C wrote:
On 05.01.2012 12:26, A.L.E.C wrote:
I've started working on the framework. The list of backward compatibity breaks will be long. Here's the first part.
And more:
[...]
Can we write all the changed and deprecated functions from devel-framework down on a wiki page? It will be essential for plugin developers to have a complete list of function call which need to be changed.
~Thomas
On 04/13/2012 04:49 PM, Thomas Bruederli wrote:
Can we write all the changed and deprecated functions from devel-framework down on a wiki page? It will be essential for plugin developers to have a complete list of function call which need to be changed.
We could. All deprecated global functions are in main.inc. There are some deprecated methods too, they are put in "deprecated" sections of some classes like rcube_message and rcube_storage.
-
A.L.E.C -
Claudio Kuenzler -
Phil Weir -
Raoul Bhatia [IPAX] -
Thomas Bruederli -
Thomas Bruederli -
till