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