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 <[email protected]> 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<[email protected]> 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< >>> [email protected]> 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<[email protected]> 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<[email protected]> 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<[email protected]> >>>>>> >>>>> 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<[email protected]> >>>>>>>> >>>>>>> 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< >>>>>>>>>> >>>>>>>>> [email protected]> >>> >>>> 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<[email protected]> >>>>>>>>>>> >>>>>>>>>> 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< >>>>>>>>>>>> >>>>>>>>>>> [email protected]> >>>> >>>>> 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"<[email protected]> >>>>>>>>>>>>> >>>>>>>>>>>> wrote: >>> >>>> Wouldn't this be resolved with our SemVer sqwitch? >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Dec 11, 2014 at 11:36 AM, Kepner, Jeremy - 0553 - >>>>>>>>>>>>>> >>>>>>>>>>>>> MITLL< >>> >>>> [email protected]> 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. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>> >>
