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 <vi...@apache.org> 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 <afu...@apache.org> 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 <josh.el...@gmail.com> 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<kep...@ll.mit.edu> >> 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<bil...@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<mad...@cloudera.com> >> 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<bil...@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"<vi...@apache.org> wrote: >>>>>>>>> >>>>>>>>>> Wouldn't this be resolved with our SemVer sqwitch? >>>>>>>>>> >>>>>>>>>> On Thu, Dec 11, 2014 at 11:36 AM, Kepner, Jeremy - 0553 - MITLL< >>>>>>>>>> kep...@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. >>>>>>>>>>> >>> >>
