accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject [DISCUSS] More Versioning Discussion
Date Thu, 17 Apr 2014 22:56:57 GMT
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
View raw message