On Wed, Oct 8, 2014 at 7:16 PM, dlmarion <[email protected]> wrote:
> Personally I think this discussion is headed in the wrong direction. I > would suggest picking a release numbering policy. Then, develop the > features for the release and adjust the release number based on the client > api changes caused by the changes in the release. If someone needs a > feature but cant afford the client api change, then try to backport it. We > should try to move forward. > > Certainly... and we've agreed to that idea (though not the specific policy) in previous conversations, starting with 2.0.0. We have not established that we would attempt to do this in any way for any 1.x releases, though it sounds like tending towards that is the general desire. > > > <div>-------- Original message --------</div><div>From: Adam Fuchs < > [email protected]> </div><div>Date:10/08/2014 6:55 PM (GMT-05:00) > </div><div>To: [email protected],Jeremy Kepner <[email protected]> > </div><div>Subject: Re: Deprecation removal for 1.7.0 </div><div> > </div>What's the right level of review? Should we have a public > announcement > board of some sort on the website, or is a request for comment on the > user list sufficient? > > On Wed, Oct 8, 2014 at 5:35 PM, Jeremy Kepner <[email protected]> wrote: > > Perhaps the process should be changed to require review prior to > deletion. > > We can't assume all our users are always scanning the e-mail list. > > It is a reasonable expectation that we won't break their code. > > >
