Re: Decreasing the Deprecation Time
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 <shaz...@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 <anis.ka...@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 <kwal...@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 [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 <mich...@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
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 <anis.ka...@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 <kwal...@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 [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 <mich...@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
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 kwal...@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 [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 mich...@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
+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.comwrote: 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
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.comwrote: 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
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.orgwrote: 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 bows...@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
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.orgwrote: 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 bows...@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
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@gmail.comwrote: 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.orgwrote: 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 bows...@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
+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 mmo...@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@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.orgwrote: 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 bows...@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
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
Decreasing the Deprecation Time
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
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 bows...@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
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 anis.ka...@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 bows...@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
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 bows...@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
