t;> > --
>> >
>> > Ken Wallis
>> >
>> > Product Manager – WebWorks
>> >
>> > BlackBerry
>> >
>> > 289-261-4369
>> >
>> >
>> > From: Marcel Kinard [c
gt; --
> >
> > Ken Wallis
> >
> > Product Manager – WebWorks
> >
> > BlackBerry
> >
> > 289-261-4369
> >
> > ____________
> > From: Marcel Kinard [cmarc...@gmail.com]
> > Sent: Friday, March 15, 2013 9:24 AM
> > To: dev@cordova.apache.org
> &
ard [cmarc...@gmail.com]
> Sent: Friday, March 15, 2013 9:24 AM
> To: dev@cordova.apache.org
> Subject: Re: Decreasing the Deprecation Time
>
> On Mar 14, 2013, at 11:02 PM, Michael Brooks
> wrote:
>
> > +1 for switching the deprecation window from time to release. Michal
>
Subject: Re: Decreasing the Deprecation Time
On Mar 14, 2013, at 11:02 PM, Michael Brooks wrote:
> +1 for switching the deprecation window from time to release. Michal summed
> it up perfectly.
Agreed.
>
> It's worth reflecting on Tommy and Simon's input. The deprecatio
On Mar 14, 2013, at 11:02 PM, Michael Brooks wrote:
> +1 for switching the deprecation window from time to release. Michal summed
> it up perfectly.
Agreed.
>
> It's worth reflecting on Tommy and Simon's input. The deprecation window is
> there to give users adequate warning that breakage is
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
+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
On Tue, Mar 12, 2013 at 8:06 PM, Tommy-Carlos Williams
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 for
+1 to decreasing the time. Right now on the wiki we have to have a ballpark
on when to deprecate in the "Remove By" column, and while it's easy to
guess because of my monthly schedule, it is less precise:
http://wiki.apache.org/cordova/DeprecationPolicy
On Wed, Mar 13, 2013 at 8:32 AM, Michal Mo
Huge +1 to decreasing the time. I also *really* like the suggestion of
moving towards deprecation time in-terms-of-releases. This is easier to
track for everyone. It also means we can leverage changes to the way we
manage releases in git (so, for example, we can give even longer-term
support for
given the reasoning presented by Joe and Tommy, I'm +1 for this.
It strikes me that a project which releases as often as ours (~1/month)
needs to have a deprecation policy based on that, not an arbitrary fixed
length of time.
On Tue, Mar 12, 2013 at 5:06 PM, Tommy-Carlos Williams
wrote:
> Just m
An alternative, for the big breaking changes in 3.0, would be to allow it
to be a clean, break-everything jump, and then support the last 2.x release
for six months, fixing major bugs and doing point releases if necessary.
Braden
On Tue, Mar 12, 2013 at 8:06 PM, Tommy-Carlos Williams
wrote:
> J
Just my $0.02, but it almost seems like you are hampering yourselves while at
the same time introducing very little in the way of stability anyway.
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.
As a
ya sorry guys, will get to that as a part of the notes sometime in the
next few days.
On Tue, Mar 12, 2013 at 3:23 PM, Anis KADRI wrote:
> I'd like to wait for Brian to post his notes but I believe that we have
> come to a consensus on this with our git workflow discussion. In general, I
> believ
I'd like to wait for Brian to post his notes but I believe that we have
come to a consensus on this with our git workflow discussion. In general, I
believe that not documenting broken APIs is worse than just breaking them.
On Tue, Mar 12, 2013 at 3:14 PM, Joe Bowser wrote:
> Hey
>
> When we fir
Hey
When we first set up the deprecation policy, we did it because we
didn't anticipate that we would create massive breakage with Cordova.
Unfortunately as we get closer to 3.0, it seems clear that we agreed
on a policy that isn't allowing us to develop as fast as we would
like. For example, we
16 matches
Mail list logo
