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