RE: Planning on CakePHP future versions

2006-10-25 Thread Mariano Iglesias
om [mailto:[EMAIL PROTECTED] En nombre de Dr. Tarique Sani Enviado el: Jueves, 26 de Octubre de 2006 01:57 a.m. Para: cake-php@googlegroups.com Asunto: Re: Planning on CakePHP future versions @MI - I am exactly doing what you are suggesting :) I head a few open source projects which have more tha

Re: Planning on CakePHP future versions

2006-10-25 Thread Dr. Tarique Sani
On 10/25/06, nate <[EMAIL PROTECTED]> wrote: > we usually completely ignore any bugs reported > on the mailing list, as they should be reported on Trac. OK! I will have the programmer who found this put it in trac and hope is it looked into. > The first case, however, is probably our fault for n

RE: Planning on CakePHP future versions

2006-10-25 Thread Mariano Iglesias
e development and/or documentation efforts. That's the way open source projects work in the end. -MI -Original Message- From: cake-php@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of nate Sent: Wednesday, October 25, 2006 2:37 PM To: Cake PHP Subject: Re: Planning on CakePHP future ver

Re: Planning on CakePHP future versions

2006-10-25 Thread nate
The second case I can't really help you out on, since the plugins interface is the one department of the framework I tend to stay out of, but I will say that yes, we usually completely ignore any bugs reported on the mailing list, as they should be reported on Trac. The first case, however, is pr

Re: Planning on CakePHP future versions

2006-10-25 Thread Dr. Tarique Sani
On 10/25/06, Martin Schapendonk <[EMAIL PROTECTED]> wrote: > > 2006/10/25, Dr. Tarique Sani <[EMAIL PROTECTED]>: > > I am now curious as to where we did not play by the rules in the above > > two cases :) > > I suppose you should have filed a ticket in Trac (http://trac.cakephp.org/). True, Had d

Re: Planning on CakePHP future versions

2006-10-25 Thread Martin Schapendonk
2006/10/25, Dr. Tarique Sani <[EMAIL PROTECTED]>: > I am now curious as to where we did not play by the rules in the above > two cases :) I suppose you should have filed a ticket in Trac (http://trac.cakephp.org/). Martin -- Martin Schapendonk, [EMAIL PROTECTED] --~--~-~--~~

Re: Planning on CakePHP future versions

2006-10-25 Thread Dr. Tarique Sani
On 10/24/06, nate <[EMAIL PROTECTED]> wrote: > > In what way did it break your apps? I'm curious because in the last Thanks for the attention - here it goes In the security fix release - Components were suddenly not available in the contructor of app_controller.php of an application - this was

RE: Planning on CakePHP future versions

2006-10-24 Thread Mariano Iglesias
@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of nate Sent: Tuesday, October 24, 2006 1:52 PM To: Cake PHP Subject: Re: Planning on CakePHP future versions What I'm saying about Java is that it's usually a bit more complex than a quick S&R. -- No virus found in this ou

Re: Planning on CakePHP future versions

2006-10-24 Thread nate
What I'm saying about Java is that it's usually a bit more complex than a quick S&R. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com T

RE: Planning on CakePHP future versions

2006-10-24 Thread Mariano Iglesias
AIL PROTECTED] On Behalf Of nate Sent: Tuesday, October 24, 2006 1:31 PM To: Cake PHP Subject: Re: Planning on CakePHP future versions The Java argument also doesn't really hold up, because in most cases, methods are simply renamed, or moved to a different object. Which means that updating an

Re: Planning on CakePHP future versions

2006-10-24 Thread nate
The Java argument also doesn't really hold up, because in most cases, methods are simply renamed, or moved to a different object. Which means that updating an app to the current release is usually a simple matter of a search-and-replace. It also doesn't hurt to be an efficient coder, and have au

RE: Planning on CakePHP future versions

2006-10-24 Thread Mariano Iglesias
al Message- From: cake-php@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of funkyfresh Sent: Tuesday, October 24, 2006 12:11 PM To: Cake PHP Subject: Re: Planning on CakePHP future versions Guys, my own opinion on this. For the future stability and wider acceptance of CakePHP, you should never

Re: Planning on CakePHP future versions

2006-10-24 Thread gwoo
We do not remove deprecated until there is a major version change. Nate was referring to methods that have been deprecated since 0.10, which came out over a year ago. Otherwise, trigger_error is used to send a warning. The most important thing here is that we need communication from the commu

Re: Planning on CakePHP future versions

2006-10-24 Thread funkyfresh
Guys, my own opinion on this. For the future stability and wider acceptance of CakePHP, you should never remove any deprecated methods. Anything that introduces instability into the product, reduces its acceptance into the wider developer community. At the least, you end up stuck on older relea

RE: Planning on CakePHP future versions

2006-10-24 Thread Mariano Iglesias
e on! -MI -Original Message- From: cake-php@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Samuel DeVore Sent: Tuesday, October 24, 2006 10:46 AM To: cake-php@googlegroups.com Subject: Re: Re: Planning on CakePHP future versions Nate is it possible to have deprecated methods through

Re: Re: Planning on CakePHP future versions

2006-10-24 Thread Samuel DeVore
Nate is it possible to have deprecated methods through notices in debug mode but work in deployment for deprecated methods for a release or two before the scheduled removal. Given that there are more and more sites built on CakePHP that are in production? SD On 10/24/06, nate <[EMAIL PROTECTED]

Re: Planning on CakePHP future versions

2006-10-24 Thread nate
In what way did it break your apps? I'm curious because in the last release, we started removing deprecated methods, which will happen again in 1.2. The methods that were removed in the previous release had been deprecated for several release cycles, some even before 1.0 final. So, I guess the

Re: Planning on CakePHP future versions

2006-10-24 Thread Dr. Tarique Sani
On 10/23/06, gwoo <[EMAIL PROTECTED]> wrote: so for some time you should have no worries about dropping the cake core into any project and watchingit work. I would like to qualify the above with "watch it work most of the time" Last two minor versions of cake broke my Cheesecake app which was runn

RE: Planning on CakePHP future versions

2006-10-23 Thread Mariano Iglesias
glegroups.com Subject: Re: Planning on CakePHP future versions The API is not changing until 2.0, so for some time you should have no worries about dropping the cake core into any project and watching it work. We are writing documentation for 1.2, but the goal is to allow people to easily upgrade withou

Re: Planning on CakePHP future versions

2006-10-23 Thread gwoo
The API is not changing until 2.0, so for some time you should have no worries about dropping the cake core into any project and watching it work. We are writing documentation for 1.2, but the goal is to allow people to easily upgrade without any worry. To us, there is no point in creating

Re: Planning on CakePHP future versions

2006-10-23 Thread Samuel DeVore
just for kicks I did move a couple of sample projects to the new core stuff and other then the chaning of the index.php files and some tweeking of config files they all seemed to move fine. No rigorous testing but initially pretty good Sam D On 10/23/06, Mariano Iglesias <[EMAIL PROTECTED]> wro