Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of tommy@devgeeks.org designates
 209.85.223.171 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: Decreasing the Deprecation Time
From: Tommy-Carlos Williams <tommy@devgeeks.org>
In-Reply-To: 
 <CAOBL_k73rUciYtjj-+9St-G8tSDUv_-C0cmzvc03bQb8B+wVBg@mail.gmail.com>
Date: Wed, 13 Mar 2013 11:06:48 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <935AA6B7-E856-4280-A10E-BF01358C2527@devgeeks.org>
References: 
 <CAOBL_k73rUciYtjj-+9St-G8tSDUv_-C0cmzvc03bQb8B+wVBg@mail.gmail.com>
To: dev@cordova.apache.org

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=85 better not use =
that=85", 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
>=20
> 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.
>=20
> 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).
>=20
> Any thoughts on this?
>=20
> Joe