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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 > >> >
