Decreasing the Deprecation Time

[Joe Bowser <bo...@gmail.com>]

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 had to wait six months to remove old history
code that we could have safely removed three months ago when it was
clear that maintaining our own history was not the right way to work
around issues.

So, I propose that we change the deprecation policy from six months to
the past three releases.  Since we release once a month at most, this
will allow us to update the software without having the overhead that
we currently have with the current policy.  Point releases (i.e.
2.5.1) would not count as a release under this policy, it would have
to be a minor release (i.e. 2.5.0) or a major release (3.0).

Any thoughts on this?

Joe

Re: Decreasing the Deprecation Time

[Shazron <sh...@gmail.com>]

For those that don't have the original thread:
https://lists.apache.org/thread.html/f36ca4df2e8d4f1713e02daa2f9b91552779fd3dea1bea430019a8dc@1363226956@%3Cdev.cordova.apache.org%3E

On Mon, Mar 13, 2017 at 2:29 PM, Shazron <sh...@gmail.com> wrote:

> Since this has gone through the 48 month cooling off period (stole that
> line from Jesse who brought this up when cleaning the Wiki), I think by
> consensus, as originally proposed by Joe, the deprecation period is now 3
> releases instead of 6 months. Finally, we can put this issue behind us!
>
> On Fri, Mar 15, 2013 at 8:07 AM, Anis KADRI <an...@gmail.com> wrote:
>
>> To Tommy-Carlos' point, I believe plugins (or the plugin interface) will
>> unlikely break when we get closer to 3.0. Reason is: if the plugin
>> interface breaks then everything will break :-D We certainly don't want
>> that.
>>
>>
>> On Fri, Mar 15, 2013 at 7:25 AM, Ken Wallis <kw...@blackberry.com>
>> wrote:
>>
>> > We will definitely care as well as we move directly on top of Cordova.
>> >  Cordova is being adopted more and more as a platform that others will
>> > build on.  A certain level of predictability and stability in a
>> platform is
>> > certainly appreciated at least. ;)
>> >
>> > We will be heavily invested in the plug-in approach here at BlackBerry
>> so
>> > that is of special concern if it is unstable.
>> >
>> >
>> > --
>> >
>> > Ken Wallis
>> >
>> > Product Manager – WebWorks
>> >
>> > BlackBerry
>> >
>> > 289-261-4369
>> >
>> > ________________________________________
>> > From: Marcel Kinard [cmarcelk@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 <mi...@michaelbrooks.ca>
>> > 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 impending.
>> However,
>> > > it's just make-work for us, if our user's don't care or take action.
>> >
>> > I care. Or in other words, the users of my product (which embeds
>> Cordova)
>> > care. I get yelled at by my users when their app breaks when doing an
>> > in-place upgrade from version n-3 to n of Cordova.
>> >
>> > -- Marcel
>> >
>> > ---------------------------------------------------------------------
>> > This transmission (including any attachments) may contain confidential
>> > information, privileged material (including material protected by the
>> > solicitor-client or other applicable privileges), or constitute
>> non-public
>> > information. Any use of this information by anyone other than the
>> intended
>> > recipient is prohibited. If you have received this transmission in
>> error,
>> > please immediately reply to the sender and delete this information from
>> > your system. Use, dissemination, distribution, or reproduction of this
>> > transmission by unintended recipients is not authorized and may be
>> unlawful.
>> >
>>
>
>

Re: Decreasing the Deprecation Time

[Shazron <sh...@gmail.com>]

Since this has gone through the 48 month cooling off period (stole that
line from Jesse who brought this up when cleaning the Wiki), I think by
consensus, as originally proposed by Joe, the deprecation period is now 3
releases instead of 6 months. Finally, we can put this issue behind us!

On Fri, Mar 15, 2013 at 8:07 AM, Anis KADRI <an...@gmail.com> wrote:

> To Tommy-Carlos' point, I believe plugins (or the plugin interface) will
> unlikely break when we get closer to 3.0. Reason is: if the plugin
> interface breaks then everything will break :-D We certainly don't want
> that.
>
>
> On Fri, Mar 15, 2013 at 7:25 AM, Ken Wallis <kw...@blackberry.com>
> wrote:
>
> > We will definitely care as well as we move directly on top of Cordova.
> >  Cordova is being adopted more and more as a platform that others will
> > build on.  A certain level of predictability and stability in a platform
> is
> > certainly appreciated at least. ;)
> >
> > We will be heavily invested in the plug-in approach here at BlackBerry so
> > that is of special concern if it is unstable.
> >
> >
> > --
> >
> > Ken Wallis
> >
> > Product Manager – WebWorks
> >
> > BlackBerry
> >
> > 289-261-4369
> >
> > ________________________________________
> > From: Marcel Kinard [cmarcelk@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 <mi...@michaelbrooks.ca>
> > 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 impending.
> However,
> > > it's just make-work for us, if our user's don't care or take action.
> >
> > I care. Or in other words, the users of my product (which embeds Cordova)
> > care. I get yelled at by my users when their app breaks when doing an
> > in-place upgrade from version n-3 to n of Cordova.
> >
> > -- Marcel
> >
> > ---------------------------------------------------------------------
> > This transmission (including any attachments) may contain confidential
> > information, privileged material (including material protected by the
> > solicitor-client or other applicable privileges), or constitute
> non-public
> > information. Any use of this information by anyone other than the
> intended
> > recipient is prohibited. If you have received this transmission in error,
> > please immediately reply to the sender and delete this information from
> > your system. Use, dissemination, distribution, or reproduction of this
> > transmission by unintended recipients is not authorized and may be
> unlawful.
> >
>

Re: Decreasing the Deprecation Time

[Anis KADRI <an...@gmail.com>]

To Tommy-Carlos' point, I believe plugins (or the plugin interface) will
unlikely break when we get closer to 3.0. Reason is: if the plugin
interface breaks then everything will break :-D We certainly don't want
that.


On Fri, Mar 15, 2013 at 7:25 AM, Ken Wallis <kw...@blackberry.com> wrote:

> We will definitely care as well as we move directly on top of Cordova.
>  Cordova is being adopted more and more as a platform that others will
> build on.  A certain level of predictability and stability in a platform is
> certainly appreciated at least. ;)
>
> We will be heavily invested in the plug-in approach here at BlackBerry so
> that is of special concern if it is unstable.
>
>
> --
>
> Ken Wallis
>
> Product Manager – WebWorks
>
> BlackBerry
>
> 289-261-4369
>
> ________________________________________
> From: Marcel Kinard [cmarcelk@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 <mi...@michaelbrooks.ca>
> 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 impending. However,
> > it's just make-work for us, if our user's don't care or take action.
>
> I care. Or in other words, the users of my product (which embeds Cordova)
> care. I get yelled at by my users when their app breaks when doing an
> in-place upgrade from version n-3 to n of Cordova.
>
> -- Marcel
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>

RE: Decreasing the Deprecation Time

[Ken Wallis <kw...@blackberry.com>]

We will definitely care as well as we move directly on top of Cordova.  Cordova is being adopted more and more as a platform that others will build on.  A certain level of predictability and stability in a platform is certainly appreciated at least. ;)  

We will be heavily invested in the plug-in approach here at BlackBerry so that is of special concern if it is unstable. 


--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369

________________________________________
From: Marcel Kinard [cmarcelk@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 <mi...@michaelbrooks.ca> 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 impending. However,
> it's just make-work for us, if our user's don't care or take action.

I care. Or in other words, the users of my product (which embeds Cordova) care. I get yelled at by my users when their app breaks when doing an in-place upgrade from version n-3 to n of Cordova.

-- Marcel

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Re: Decreasing the Deprecation Time

[Marcel Kinard <cm...@gmail.com>]

On Mar 14, 2013, at 11:02 PM, Michael Brooks <mi...@michaelbrooks.ca> 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 impending. However,
> it's just make-work for us, if our user's don't care or take action.

I care. Or in other words, the users of my product (which embeds Cordova) care. I get yelled at by my users when their app breaks when doing an in-place upgrade from version n-3 to n of Cordova.

-- Marcel

Re: Decreasing the Deprecation Time

[Tommy-Carlos Williams <to...@devgeeks.org>]

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 <mi...@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
> <si...@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
>> 

Re: Decreasing the Deprecation Time

[Michael Brooks <mi...@michaelbrooks.ca>]

+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
<si...@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
>

Re: Decreasing the Deprecation Time

[Simon MacDonald <si...@gmail.com>]

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

Re: Decreasing the Deprecation Time

[Shazron <sh...@gmail.com>]

+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 Mocny <mm...@chromium.org> wrote:

> 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 deprecated features without sacrificing regression fixes by
> having app dev switch to a "stable" branch).
>
> -Michal
>
>
> On Wed, Mar 13, 2013 at 10:45 AM, Lorin Beer <lorin.beer.dev@gmail.com
> >wrote:
>
> > 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
> > <to...@devgeeks.org>wrote:
> >
> > > 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 plugin author, I was one of the proponents of the deprecation
> > policy,
> > > yet I still feel like plugins break every 2-3 releases anyway, so why
> > hold
> > > yourselves back on other changes/features?
> > >
> > > - tommy
> > >
> > >
> > >
> > > On 13/03/2013, at 9:14 AM, Joe Bowser <bo...@gmail.com> wrote:
> > >
> > > > 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 had to wait six months to remove old history
> > > > code that we could have safely removed three months ago when it was
> > > > clear that maintaining our own history was not the right way to work
> > > > around issues.
> > > >
> > > > So, I propose that we change the deprecation policy from six months
> to
> > > > the past three releases.  Since we release once a month at most, this
> > > > will allow us to update the software without having the overhead that
> > > > we currently have with the current policy.  Point releases (i.e.
> > > > 2.5.1) would not count as a release under this policy, it would have
> > > > to be a minor release (i.e. 2.5.0) or a major release (3.0).
> > > >
> > > > Any thoughts on this?
> > > >
> > > > Joe
> > >
> > >
> >
>

Re: Decreasing the Deprecation Time

[Michal Mocny <mm...@chromium.org>]

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 deprecated features without sacrificing regression fixes by
having app dev switch to a "stable" branch).

-Michal


On Wed, Mar 13, 2013 at 10:45 AM, Lorin Beer <lo...@gmail.com>wrote:

> 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
> <to...@devgeeks.org>wrote:
>
> > 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 plugin author, I was one of the proponents of the deprecation
> policy,
> > yet I still feel like plugins break every 2-3 releases anyway, so why
> hold
> > yourselves back on other changes/features?
> >
> > - tommy
> >
> >
> >
> > On 13/03/2013, at 9:14 AM, Joe Bowser <bo...@gmail.com> wrote:
> >
> > > 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 had to wait six months to remove old history
> > > code that we could have safely removed three months ago when it was
> > > clear that maintaining our own history was not the right way to work
> > > around issues.
> > >
> > > So, I propose that we change the deprecation policy from six months to
> > > the past three releases.  Since we release once a month at most, this
> > > will allow us to update the software without having the overhead that
> > > we currently have with the current policy.  Point releases (i.e.
> > > 2.5.1) would not count as a release under this policy, it would have
> > > to be a minor release (i.e. 2.5.0) or a major release (3.0).
> > >
> > > Any thoughts on this?
> > >
> > > Joe
> >
> >
>

Re: Decreasing the Deprecation Time

[Lorin Beer <lo...@gmail.com>]

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
<to...@devgeeks.org>wrote:

> 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 plugin author, I was one of the proponents of the deprecation policy,
> yet I still feel like plugins break every 2-3 releases anyway, so why hold
> yourselves back on other changes/features?
>
> - tommy
>
>
>
> On 13/03/2013, at 9:14 AM, Joe Bowser <bo...@gmail.com> wrote:
>
> > 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 had to wait six months to remove old history
> > code that we could have safely removed three months ago when it was
> > clear that maintaining our own history was not the right way to work
> > around issues.
> >
> > So, I propose that we change the deprecation policy from six months to
> > the past three releases.  Since we release once a month at most, this
> > will allow us to update the software without having the overhead that
> > we currently have with the current policy.  Point releases (i.e.
> > 2.5.1) would not count as a release under this policy, it would have
> > to be a minor release (i.e. 2.5.0) or a major release (3.0).
> >
> > Any thoughts on this?
> >
> > Joe
>
>

Re: Decreasing the Deprecation Time

[Braden Shepherdson <br...@chromium.org>]

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
<to...@devgeeks.org>wrote:

> 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 plugin author, I was one of the proponents of the deprecation policy,
> yet I still feel like plugins break every 2-3 releases anyway, so why hold
> yourselves back on other changes/features?
>
> - tommy
>
>
>
> On 13/03/2013, at 9:14 AM, Joe Bowser <bo...@gmail.com> wrote:
>
> > 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 had to wait six months to remove old history
> > code that we could have safely removed three months ago when it was
> > clear that maintaining our own history was not the right way to work
> > around issues.
> >
> > So, I propose that we change the deprecation policy from six months to
> > the past three releases.  Since we release once a month at most, this
> > will allow us to update the software without having the overhead that
> > we currently have with the current policy.  Point releases (i.e.
> > 2.5.1) would not count as a release under this policy, it would have
> > to be a minor release (i.e. 2.5.0) or a major release (3.0).
> >
> > Any thoughts on this?
> >
> > Joe
>
>

Re: Decreasing the Deprecation Time

[Tommy-Carlos Williams <to...@devgeeks.org>]

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 plugin author, I was one of the proponents of the deprecation policy, yet I still feel like plugins break every 2-3 releases anyway, so why hold yourselves back on other changes/features?

- tommy



On 13/03/2013, at 9:14 AM, Joe Bowser <bo...@gmail.com> wrote:

> 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 had to wait six months to remove old history
> code that we could have safely removed three months ago when it was
> clear that maintaining our own history was not the right way to work
> around issues.
> 
> So, I propose that we change the deprecation policy from six months to
> the past three releases.  Since we release once a month at most, this
> will allow us to update the software without having the overhead that
> we currently have with the current policy.  Point releases (i.e.
> 2.5.1) would not count as a release under this policy, it would have
> to be a minor release (i.e. 2.5.0) or a major release (3.0).
> 
> Any thoughts on this?
> 
> Joe

Re: Decreasing the Deprecation Time

[Brian LeRoux <b...@brian.io>]

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 <an...@gmail.com> 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
> believe that not documenting broken APIs is worse than just breaking them.
>
>
> On Tue, Mar 12, 2013 at 3:14 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>> 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 had to wait six months to remove old history
>> code that we could have safely removed three months ago when it was
>> clear that maintaining our own history was not the right way to work
>> around issues.
>>
>> So, I propose that we change the deprecation policy from six months to
>> the past three releases.  Since we release once a month at most, this
>> will allow us to update the software without having the overhead that
>> we currently have with the current policy.  Point releases (i.e.
>> 2.5.1) would not count as a release under this policy, it would have
>> to be a minor release (i.e. 2.5.0) or a major release (3.0).
>>
>> Any thoughts on this?
>>
>> Joe
>>

Re: Decreasing the Deprecation Time

[Anis KADRI <an...@gmail.com>]

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 <bo...@gmail.com> wrote:

> 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 had to wait six months to remove old history
> code that we could have safely removed three months ago when it was
> clear that maintaining our own history was not the right way to work
> around issues.
>
> So, I propose that we change the deprecation policy from six months to
> the past three releases.  Since we release once a month at most, this
> will allow us to update the software without having the overhead that
> we currently have with the current policy.  Point releases (i.e.
> 2.5.1) would not count as a release under this policy, it would have
> to be a minor release (i.e. 2.5.0) or a major release (3.0).
>
> Any thoughts on this?
>
> Joe
>