On Fri, Jun 2, 2017 at 2:15 PM Josh Elser <els...@apache.org> wrote: > Upgrade compatibility doesn't necessary mean that real organizations can > perform the upgrade (I've seen my fair-share of reasons that > organization cannot/will-not upgrade for some period of time). This > typically has a minimum time-line of a couple of months to make and > schedule the work. > > True, and I can think of some reasons that would make my own life difficult (dependency convergence in Fedora RPM packages might make it hard to update to a new backwards-compatible version which has new dependencies).
However, I'm also coming at this from some perspectives I've gotten from users at $dayjob. When we released 1.7.3 and 1.8.1, several people emailed me with some confusion, asking which one they should upgrade to. In general, when people are considering such upgrades, I would simply recommend the later one, so that's what I did... but then they asked me, "Who exactly is 1.7.3 for, then?" and I couldn't really think of an answer I thought was a good one. For most people... either you can upgrade or you can't. If you can upgrade, upgrade to the latest one which is compatible. If you can't upgrade, then why care about 1.7.3? I realize there's some cases, where upgrading to 1.7.3 is easy, but 1.8.1 is harder... my own example above. But, from my understanding of how most users package and deploy Accumulo with bundled dependencies, I can't imagine many scenarios where there's a reason to upgrade only to 1.7.3 instead of going to 1.8.1, except that we, as developers have provided that option... some there may be some perceptions that the larger jump is riskier in some way (when that's not necessarily the case, especially once the new line has had a chance to have been shown to be stable). The user confusion is exacerbated by the fact that sometimes the release timing results in the earlier release line having bug fixes which have not yet made it in to the newer release line. And, our motivation to do a new release in the newer line is lowered from having recently done two prior releases. If we weren't doing new bugfixes in the previous line after the latest has stabilized, there'd probably be more motivation to do more bugfix releases in the latest line. > I assume we have no idea about who is using what version -- sending a > note to users@ would might generate some helpful feedback. We could also > look at known downstream integrations to see if they have done 1.8 > testing (e.g. Pig, Hive, Presto), if nothing else, to let them all know > "change is a'coming". > > Is there any chance you'd be willing to pose some questions to the user list to solicit some feedback? I fear that I won't be able to frame the questions well enough to get the kind of feedback we need to decide on something like this. > As a developer, I'd like to retire 1.7, but I'm not sure if it's > realistic yet. Regardless, this conversation is certainly a good idea. > > > On 6/1/17 6:33 PM, Christopher wrote: > > Now that we do semver, and 1.8 has been broken in a bit, do we need to > > continue to support 1.7 releases with bugfixes? There is a fully > > backwards-compatible upgrade path from 1.7 to 1.8. So, it seems we > probably > > don't need to support new 1.7.x to 1.7.(x+1) upgrade paths any more. > > > > Not sure. Thoughts? > > >
