Return-Path: X-Original-To: apmail-accumulo-dev-archive@www.apache.org Delivered-To: apmail-accumulo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 30336C470 for ; Thu, 11 Dec 2014 23:08:32 +0000 (UTC) Received: (qmail 57353 invoked by uid 500); 11 Dec 2014 23:08:32 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 57313 invoked by uid 500); 11 Dec 2014 23:08:32 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 57300 invoked by uid 99); 11 Dec 2014 23:08:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Dec 2014 23:08:31 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of josh.elser@gmail.com designates 209.85.216.172 as permitted sender) Received: from [209.85.216.172] (HELO mail-qc0-f172.google.com) (209.85.216.172) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Dec 2014 23:08:26 +0000 Received: by mail-qc0-f172.google.com with SMTP id m20so4769111qcx.31 for ; Thu, 11 Dec 2014 15:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=AJZm80MUl1ZmvsL6WDE5254jTw8i7kLeMRv/JVI0PEY=; b=XaFGPBnf9p/5gvJz99Y3JtNggrfSvQEE/hcbezLpXHtwEBcSEp277rvf0piUeOF466 lii68JGw9JczEm/GSd0ICYkd1F2JPLqGBMAy9NqG/M/TsW0MiqHprC/74hYFDOaGa0Gv +4WnIJaqWg+2EdtZikxeM3YDL5vv3yE1wHXdrX+CPBSPUVe1aKu9l6SzgtYZPS+z1hMX bmlTX1jXPi7l5ZnVr4ooHP7UfxQX+RmOLb5lHiAghTUaN5A3PSchkcVVUZdtRSFZc4hw ddyNTSQkUAxFaxUthqa6H4CTnfkni938nFFm0AQQ9iS8P7lyWFaVEmoUf1HUNa2j2Ge/ +TdA== X-Received: by 10.229.63.71 with SMTP id a7mr25324769qci.24.1418339285716; Thu, 11 Dec 2014 15:08:05 -0800 (PST) Received: from HW10447.local (penguinsinabox.com. [97.107.135.153]) by mx.google.com with ESMTPSA id k11sm2402248qgf.18.2014.12.11.15.08.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Dec 2014 15:08:05 -0800 (PST) Message-ID: <548A23D3.2000804@gmail.com> Date: Thu, 11 Dec 2014 18:08:03 -0500 From: Josh Elser User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: dev@accumulo.apache.org Subject: Re: Official Guidance to users regarding removal of functions References: <20141211185403.GA10747@ll.mit.edu> <5489EF68.2040500@gmail.com> <548A13B2.8010600@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Great, thanks for the feedback. I just committed this in ACCUMULO-3403 Christopher wrote: > Yes, I agree you should just reintroduce the method if it was removed in > 1.7, which is not yet released. > If it was removed in 1.6.{0,1}, you could also consider reintroducing it > for 1.6.2, to support those users also. > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > On Thu, Dec 11, 2014 at 4:59 PM, Josh Elser wrote: > >> For context and as a good example of how we could be less abrasive, I'm >> unexpectedly spending today updating Hive with a bunch of new reflection >> because methods in 1.5 on AccumuloInputFormat no longer exist in 1.7. >> setZooKeeperInstance used to take two Strings, but in 1.7 this version of >> the method was removed and forces client to use ClientConfiguration. >> >> This is a good example of where we didn't have to do this and there was >> next to no maintenance support on us to preserve this method. >> >> Honestly, after writing this, I'm tempted to reinstate the old version >> because doing this amount of reflection is painful and silly for clients >> (and I even know what I'm doing most days!) >> >> Mike Drob wrote: >> >>> FWIW, Java 9 is dropping methods for the first time that the JDK API is >>> dropping methods. Almost 20 years. Just something to consider, when we >>> approach the conversation of how long to keep APIs around. >>> >>> On Thu, Dec 11, 2014 at 3:46 PM, Christopher wrote: >>> >>> You seem to be dismissing "clean up" as an invalid. I disagree. There are >>>> costs to keeping around deprecated APIs. That's not to say we shouldn't >>>> keep them around for a long time... we can and perhaps should. But "clean >>>> up" is just shorthand for all the maintainability, readability, and >>>> usability costs. As such, I feel it incapsulates many reasons which are >>>> sometimes difficult to express, but still valid. >>>> >>>> With semver in place, it seems like your position could be reduced to >>>> "support major versions longer", which is a perfectly fine goal. As long >>>> as >>>> we have that, there's really no need to upgrade to the "latest", unless >>>> there's a feature that you want which is difficult to backport in a minor >>>> release. In that case, I think it's perfectly reasonable to consider the >>>> risks of upgrading and to make the choice to upgrade and have the feature >>>> or not upgrade and avoid API changes which affect you (if any). >>>> >>>> >>>> -- >>>> Christopher L Tubbs II >>>> http://gravatar.com/ctubbsii >>>> >>>> On Thu, Dec 11, 2014 at 3:19 PM, Kepner, Jeremy - 0553 - MITLL< >>>> kepner@ll.mit.edu> wrote: >>>> >>>> So I think the bigger issue is to revisit the imperative to delete >>>>> deprecated functions (both public& private). How many instances have >>>>> we >>>>> had where deleting a deprecated API (public& private) did anything more >>>>> >>>>> than "clean up" the code? >>>>> >>>>> On Dec 11, 2014, at 2:39 PM, John Vines wrote: >>>>> >>>>> More likely we'd have a fully backwards compatible API for each major >>>>>> version. SemVer allows for it and I think that grants us enough room >>>>>> >>>>> for >>>>> growth while still securing things for future releases. >>>>>> On Thu, Dec 11, 2014 at 2:36 PM, Adam Fuchs wrote: >>>>>> >>>>>> Awesome -- ACCUMULO-2589 gets us at least halfway there. Given this, >>>>>>> what would be the challenges in having and maintaining one API project >>>>>>> for each major version ever released? >>>>>>> >>>>>>> Adam >>>>>>> >>>>>>> On Thu, Dec 11, 2014 at 2:24 PM, Josh Elser >>>>>>> >>>>>> wrote: >>>>>> Adam Fuchs wrote: >>>>>>>>> Has anybody looked into separating the public API a bit more from >>>>>>>>> >>>>>>>> the >>>>> core? It seems to me that a large number of the deprecation removal >>>>>>>>> issues are related to people failing to read section 9 of the >>>>>>>>> >>>>>>>> README. >>>>> It would be great if we built an API jar that people could build >>>>>>>>> against, but didn't leak internal classes. Maybe this is something >>>>>>>>> >>>>>>>> we >>>>> can shoot for in the 2.0 release? >>>>>>>> Yup, this is already in the works by Christopher as a part of >>>>>>>> >>>>>>> ACCUMULO-2589. >>>>>>> >>>>>>>> Taking that a step further, it would be great if we released a 1.x >>>>>>>> API >>>>> compatible client jar for every 2.x or later release. Does anybody >>>>>>>>> have a feel for the maintenance costs of such a thing? Certainly >>>>>>>>> changes to configuration options and metadata table structures will >>>>>>>>> prove challenging. Given that we don't have a history of removing >>>>>>>>> functionality, this ought to at least be feasible. >>>>>>>>> >>>>>>>>> Thoughts? >>>>>>>>> >>>>>>>>> Adam >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Dec 11, 2014 at 1:54 PM, Jeremy Kepner >>>>>>>>> >>>>>>>> wrote: >>>>>>>> So the simple solution is to deprecate often, but remove almost >>>>>>>>> never. >>>>>> It is very rare that leaving a deprecated API in place actually >>>>>>>>> has a >>>>> negative impact. >>>>>>>>>> The code gets a little less clean, but that's fine as long as >>>>>>>>>> >>>>>>>>> things >>>>> are >>>>>>>> clearly labeled as deprecated. >>>>>>>>>> In fact, seeing the way something used to be done can often be an >>>>>>>>>> inspiration for something new. >>>>>>>>>> If the past is deleted, then that knowledge is lost. >>>>>>>>>> >>>>>>>>>> I am not saying deleting can never happen, I am just saying that >>>>>>>>>> >>>>>>>>> when >>>>> it >>>>>>>> does, it is because >>>>>>>>>> there absolutely no choice. Deletion to "clean up the code" >>>>>>>>>> >>>>>>>>> shouldn't >>>>>> be >>>>>>>> a valid reason for deletion. >>>>>>>>>> On Thu, Dec 11, 2014 at 12:58:13PM -0500, Christopher wrote: >>>>>>>>>> >>>>>>>>>>> I don't know that it'd be "cold comfort". We can continue to >>>>>>>>>>> >>>>>>>>>> support >>>>> 1.x >>>>>>>> for some time, if we choose. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Christopher L Tubbs II >>>>>>>>>>> http://gravatar.com/ctubbsii >>>>>>>>>>> >>>>>>>>>>> On Thu, Dec 11, 2014 at 12:53 PM, Billie Rinaldi< >>>>>>>>>>> >>>>>>>>>> billie@apache.org> >>>>> wrote: >>>>>>>>>>> Actually, I wasn't suggesting anything. I was providing >>>>>>>>>>> elaboration >>>>>> on >>>>>>>> what John was referring to. I imagine that stronger API >>>>>>>>>>> guarantees >>>>> will be >>>>>>>>>>>> cold comfort in the face of a 1.0 -> 2.0 upgrade. However, if >>>>>>>>>>>> >>>>>>>>>>> we >>>>> had >>>>>>>> been >>>>>>>>>>>> using semver all along, there would have been much less pain for >>>>>>>>>>>> >>>>>>>>>>> users >>>>>>>> in >>>>>>>>>>>> the 1.x series. Also, adopting semver would mean that going from >>>>>>>>>>>> >>>>>>>>>>> 1.6 >>>>>> to a >>>>>>>>>>>> hypothetical 1.7 would not suffer from the same upgrade issues. >>>>>>>>>>>> >>>>>>>>>>> I >>>>> doubt >>>>>>>>>>>> that we could retroactively mitigate the differences in minor >>>>>>>>>>>> >>>>>>>>>>> versions, >>>>>>>> though, so going from 1.3/1.4/1.5 to 1.7 would still be hard. >>>>>>>>>>>> On Thu, Dec 11, 2014 at 9:11 AM, Mike Drob >>>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>> Billie, >>>>>>>>>>>>> Not to be glib, but it reads like your suggestion to Jeremy for >>>>>>>>>>>>> >>>>>>>>>>>> when >>>>>> we >>>>>>>>>>>>> have a 2.0.0 release (assuming semver passes) is to take option >>>>>>>>>>>>> >>>>>>>>>>>> (2) >>>>>> Don't >>>>>>>>>>>>> upgrade Accumulo. >>>>>>>>>>>>> >>>>>>>>>>>>> Please correct my misunderstanding. >>>>>>>>>>>>> >>>>>>>>>>>>> Mike >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Dec 11, 2014 at 11:07 AM, Billie Rinaldi< >>>>>>>>>>>>> >>>>>>>>>>>> billie@apache.org> >>>>>> wrote: >>>>>>>>>>>>> To clarify John's question: if our vote to adopt semver 2.0.0 >>>>>>>>>>>>> passes, >>>>>>>> our >>>>>>>>>>>>> intention will be to no longer have breaking public API changes >>>>>>>>>>>>>> unless >>>>>>>>>>>>>> >>>>>>>>>>>>> the >>>>>>>>>>>>> >>>>>>>>>>>>>> major version number is incremented, i.e. 1.x.x -> 2.x.x. An >>>>>>>>>>>>>> important >>>>>>>>>>>>>> aspect of semantic versioning is defining what is considered >>>>>>>>>>>>>> >>>>>>>>>>>>> part >>>>> of >>>>>>>> the >>>>>>>>>>>>> public API. So if there are things you need to remain >>>>>>>>>>>>> consistent >>>>> that >>>>>>>> are >>>>>>>>>>>>> not covered by Section 9 of the README, we should discuss >>>>>>>>>>>>> adding >>>>> them. >>>>>>>>>>>>>> Actually, strengthening what we consider to be the public API >>>>>>>>>>>>>> >>>>>>>>>>>>> is >>>>> likely >>>>>>>>>>>>> to >>>>>>>>>>>>> >>>>>>>>>>>>>> be a separate conversation in which (I hope) we will engage the >>>>>>>>>>>>>> >>>>>>>>>>>>> user >>>>>>>> list. >>>>>>>>>>>>>> On Dec 11, 2014 11:51 AM, "John Vines" >>>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>> Wouldn't this be resolved with our SemVer sqwitch? >>>>>>>>>>>>>>> On Thu, Dec 11, 2014 at 11:36 AM, Kepner, Jeremy - 0553 - >>>>>>>>>>>>>>> >>>>>>>>>>>>>> MITLL< >>>>> kepner@ll.mit.edu> wrote: >>>>>>>>>>>>>>> When we remove functions, do we have any official guidance to >>>>>>>>>>>>>>> our >>>>>> users >>>>>>>>>>>>>> who may have built applications that use those functions? >>>>>>>>>>>>>>>> Right now, the official position is that the Accumulo >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> developers >>>>>> can >>>>>>>>>>>>> remove based on a consensus vote. However, this provides no >>>>>>>>>>>>>>> guidance >>>>>>>>>>>>> to >>>>>>>>>>>>> >>>>>>>>>>>>>> users as to what they are suppose to do? As it stands, our >>>>>>>>>>>>>>> guidance >>>>>>>> is >>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> they have the following choices: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (0) Diligently watch the Accumulo e-mail list and >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> aggressively >>>>> weigh >>>>>>>>>>>>> in >>>>>>>>>>>>> >>>>>>>>>>>>>> on >>>>>>>>>>>>>>>> any vote to remove functions that may impact them. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (1) Find someone to modify the original source code of their >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> applications, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> build it, and *re-verify* the application. I emphasise the >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> re-verify >>>>>>>>>>>>> because that is usually the most costly part of the process >>>>>>>>>>>>>>> that >>>>>> often >>>>>>>>>>>>>> won't get approved by management. >>>>>>>>>>>>>>>> (2) Don't upgrade Accumulo. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >