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