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 >
