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?
