accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Medinets <david.medin...@gmail.com>
Subject Re: [DISCUSS] More Versioning Discussion
Date Fri, 18 Apr 2014 13:09:49 GMT
As long as v1.4.2 client code is compatible with all subsequent releases, I
foresee no problems. Or  write a 1.4.2 to 1.X.X proxy layer.

*this is a poe*


On Thu, Apr 17, 2014 at 11:05 PM, Christopher <ctubbsii@apache.org> wrote:

> That's a fair point, but the main point I was trying to make using
> that example was that there are concrete efforts which have been made
> to inch closer to better compatibility guarantees, and
> compatibility... specifically within a supported release line... is
> something that we routinely consider and discuss.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Thu, Apr 17, 2014 at 9:51 PM, Mike Drob <madrob@cloudera.com> wrote:
> > For a little bit of historical context - when filing ACCUMULO-751 to ask
> > for wire compatibility, I had no intention of providing both forward and
> > backwards compatibility. I really wanted the ability to do rolling
> upgrades
> > where I could upgrade tablet servers one-by-one and not have suffer any
> > cluster downtime. Everything else could be completely incompatible, but
> as
> > long as the cluster could handle a part upgraded state, then that was
> fine.
> >
> >
> > On Thu, Apr 17, 2014 at 6:56 PM, Christopher <ctubbsii@apache.org>
> wrote:
> >
> >> Sean comment on ACCUMULO-2343:
> >>
> >>
> https://issues.apache.org/jira/browse/ACCUMULO-2343?focusedCommentId=13973504&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13973504
> >>
> >> I was going to comment in IRC or in response in JIRA, but I think this
> >> would better serve the group to discuss here.
> >>
> >> My response was going to be:
> >>
> >> You seem to keep insisting that we don't have consensus on basic API
> >> guarantees. I don't think that's true. We may not have a complete
> >> policy, but I think we have some agreement on some of the basics of
> >> what we want users to be able to expect. It's still a good idea to
> >> think about compatibility forwards and backwards, within a release
> >> line, and I'm pretty sure we all agree on that. Lack of complete
> >> policy is not the same as lack of agreement on some of the things that
> >> policy would contain. Perhaps we've been too permissive in the past
> >> and not pushed back as hard on it, in order to avoid controversy, but
> >> I don't think it's a lack of agreement at play.
> >>
> >> My question for the larger group is:
> >>
> >> Am I wrong? Do we, or do we not, want compatibility between different
> >> versions in a release line (1.4.x, 1.5.x, 1.6.x, etc.)?
> >>
> >> My suspicion is that we do, and it's the reason I introduced the wire
> >> version in 1.5.x, as a step towards this. I'd like us to continue
> >> making steps towards this, and even in the absence of a strict
> >> versioning policy, we take care to think about this, and be less
> >> permissive about introduction of changes within a release line that
> >> would not be compatible with previous releases in that line.
> >>
> >> In my view, *any* comprehensive versioning policy we adopt is going to
> >> include the idea that the last segment of the versioning denotes a
> >> bugfix release. Is there any possibility at all that we'd adopt a
> >> policy that doesn't include this? I think not. So, why not be more
> >> strict about this now?
> >>
> >> Personally, I'd love to start vetoing non-bugfix changes to previous
> >> release lines, but I want to ensure that I'm doing so with the
> >> community, and not against it.
> >>
> >> --
> >> Christopher L Tubbs II
> >> http://gravatar.com/ctubbsii
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message