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.
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:
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.
I know this got very long, especially for a Friday. Please bear with me. On Thu, Apr 17, 2014 at 5:56 PM, Christopher <[EMAIL PROTECTED]> wrote: I'm sure that as a community we want backwards compatibility within a major version (currently the "y" in Version # x.y.z). I have heard you and Keith argue for forward compatibility within a major version and I have heard me argue against it. Even then, we have not really had a discussion about what we mean to cover by compatibility.
We have an expressed scope of some packages in the Java API and a rough outline of major underlying services (Hadoop/ZooKeeper versions), but that's it. This is a very simplified view of compatibility. A non-exhaustive list of compatibility considerations:
* the Thrift API amongst server components (though ACCUMULO-751 implies some) * the Thrift API between clients and servers (also implied in ACCUMULO-751) * the Thrift Proxy API * Data serialized to walogs * Data serialized to backing files in HDFS (though we have a convention that's come up a couple of times) * Data serialized to ZooKeeper * Data serialized in internal tables (metadata, root, trace) * visibility expressions (and labels themselves) * iterators * The Accumulo Launcher scripts (accumulo.sh / tool.sh / the rest of bin) * The Accumulo Shell * Configuration files & defaults * Misc utility executables * The setup process * provided classpath * packaged tests * packaged examples * Log contents
Maintaining a compatibility statement across the lot of these is, frankly, going to be hard. We already have problems just keeping binary backwards compatibility and that's the one where it's easiest to leverage external tooling. We should make sure we've had a good discussion and have good docs on the boundaries before we change what we're going to expect everyone to abide by. I agree that whatever versioning policy we adopt post-1.6 will treat the z in version # x.y.z as bugfix. I also expect we will have a fairly strict compatibility restriction on it. Part of why we'll be able to do that is that having a minor version will allow developers get most new feature ideas out the door without waiting for the long release cycle of a major version.
These are our release cycles to date since coming to ASF (approx based on user@, jira, RC votes):
That's ~1 year between major releases. IMO, that'd be a good rate presuming a maintenance window of ~2 major versions (I'd even like it to be a little slower). It's also somewhere between 3-9 months between minor/bugfix versions. IMO, this is too slow for bugfix and okay for minor.
It's true that adopting the restriction you suggest will help us speed up our rate of bugfix releases in the short term. For one, we could adopt a less rigorous release testing process. That would let us set a regular clip for pushing out whatever versions had fixes, say the first Wednesday of each month.
However, there would be two detrimental affects. First, there's the frustration of additional delay for developers who want to see new features make it out. More importantly, forcing all feature additions to major versions couples them to the cost of non-backwards compatible API changes, which in turn discourages uptake with users.
Once we have clear compatibility guidelines and the ability to distinguish between major, minor, and bugfix, we should get better at hitting a regular release stride. When we have a more regular stride, people will generally be more comfortable waiting for their particular contribution to go into a later release. Furthermore, having a steady stream of non-bugfix minor upgrades that don't require client changes will help improve our current situation wrt getting more recent versions into production.
Until we have a formalized compatibility guide, I'd encourage us to allow our volunteers to target whatever version works for them so long as
1) we don't violate backwards compatibility
2) we handle stability requests with compromise positions
A good example of the latter is ACCUMULO-1395, where the example configuration scripts were left in place since many users rely on them for bootstrapping.
On Fri, Apr 18, 2014 at 10:43 AM, Sean Busbey <[EMAIL PROTECTED]> wrote:
We don't have to couple minor feature additions to major versions. We could easily continue the 1.x line with minor feature releases (1.7, 1.8, etc.) with backwards compatibility guarantees to 1.5.0 (since 1.6.0 is already backwards compatible with 1.5.0, and we can't do anything about earlier than that, but hopefully 1.4 can be EOL'd soon). My main concern with this last point is that it dramatically increases the burden on the entire community (in terms of review and testing) for what should be easy bugfix releases for supported branches. It also significantly increases the risk of destabilization for long-term support. While I think we're in full agreement for the future (post 1.6), I see no reason why we can't start adopting some of the strictness today for the older versions the community is still supporting, to immediately start gaining some of the benefits of this reduced burden (say, for 1.4.6, 1.5.2, and 1.6.1).
It seems we generally agree on what *should* be done in the future, but you're reluctant to adopt it gradually, instead creating a barrier at some version, V, after which we apply these standards, and before which (almost) anything goes. And, I think your reluctance is based partially on the concern for precedence (which I don't think is valid), and a concern for supporting minor features releases in 1.4.x and 1.5.x (which I think is valid, but I don't think we should burden ourselves with, since 1.4.x can be EOL'd soon and 1.6.0 can be roughly* viewed as a minor backwards-compatible release to 1.5.0).
* Note: I say "roughly", because 1.6.0 did remove methods deprecated in 1.5.0, and is only backwards-compatible for non-deprecated stuffs. Obviously, we can be more strict about this in future 1.x releases.
On Fri, Apr 18, 2014 at 11:42 AM, Christopher <[EMAIL PROTECTED]> wrote:
what our versions mean, still within a 1.* line. If we suddenly start making 1.7, 1.8, etc... true minor releases, then we aren't going to see the community pick them up in that way. They already have it ingrained into their consciousness that the second digit marks a major upgrade, and everything that goes with those. And if we only have two digits to work with, then major/bugfix is not a great distinction. Handcuffing ourselves to no minor releases sounds unnecessarily limiting.
I would completely support cleaning up our version promises, but only when we can do it right. Trying to do it incrementally, and especially starting from a double-dot release is just going to cause too much churn in the user base.
A passing thought, but when we get to "real" bug fix releases, I'd like to see the testing burden reduced. If there's only bug fixes, we need only test that those are fixed and don't need to hold ourselves to the week of testing IMO.
Hopefully unit and integration tests would be sufficient, but I could see a few hours of CI or RW being satisfactory. This would help reduce latency and burden in these releases. On Apr 18, 2014 11:42 AM, "Christopher" <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
Apache Lucene, Apache Solr and all other Apache Software Foundation project and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext