I actually think the work would be with it if it actually meant that things didn't break at ALL until something's window closed.. but the reality is that this is a fast moving target and things like plugins are still breaking fairly frequently (which is worse than core api's changing since core api's have nice docs and people whose full time job it is to fix them, etc… plugins, not so much).
Add to that the fact that Cordova has to respond to sudden changes in the native APIs as well as emerging platforms… The truth is that apps don't NEED to update every time Cordova does anymore. Cordova is pretty stable and works pretty well… so as long as there is a reasonable upgrade path I don't see why the deprecation window can't be made even more clear by being release-based. - tommy On 15/03/2013, at 2:02 PM, Michael Brooks <mich...@michaelbrooks.ca> wrote: > +1 for switching the deprecation window from time to release. Michal summed > it up perfectly. > > It's worth reflecting on Tommy and Simon's input. The deprecation window is > there to give users adequate warning that breakage is impending. However, > it's just make-work for us, if our user's don't care or take action. > > On Wed, Mar 13, 2013 at 7:09 PM, Simon MacDonald > <simon.macdon...@gmail.com>wrote: > >> On Tue, Mar 12, 2013 at 8:06 PM, Tommy-Carlos Williams >> <to...@devgeeks.org> wrote: >>> >>> No one sees a deprecation warning and thinks "ooh… better not use >> that…", they say "a warning is not an error" and move on with their project. >> >> What I find incredibly weird is no one cares about our deprecation >> method but god forbid your Android Java code is using a deprecated >> method or constant. I've been contacted by users days after a new >> Android version drops asking to get rid of the deprecated methods. >> >> Simon Mac Donald >> http://hi.im/simonmacdonald >>
