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. > >>>>>>>>> > > >
