cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Decreasing the Deprecation Time
Date Wed, 13 Mar 2013 18:28:24 GMT
+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 <mmocny@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
> > <tommy@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 <bowserj@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
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message