accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: [DISCUSS] Question about 1.7 bugfix releases
Date Mon, 05 Jun 2017 15:20:58 GMT
Thanks, Sean. You've rewarded my laziness in replying to Christopher :)

The only thing I have to expand on is: even though, as developers, we 
know that the 1.7.3 to 1.8.1 upgrade is no harder than to a 1.7.x, 
"reasons" (often, nonsensical or outright bad reasons) can block people 
from doing it. Policy often dictates the limitations infrastructures 
group must work with. Often, threat/worry of risk greatly exceeds actual 
risk for groups working in these environments.

On 6/5/17 10:58 AM, Sean Busbey wrote:
> Many users in enterprise spaces have rules for upgrading to
> a new maintenance release that are different from upgrading to a new
> minor release. Those rules presume a uniform understanding of the
> risks involved in each of those kinds of releases that I don't think
> exists, especially across open source projects, but nonetheless those
> are the rules the organization is stuck with. For those users,
> continued maintenance releases that include critical bug fixes are key
> to allowing them to consume our releases.
> It's true the release timing can make things awkward by getting some
> critical fix out for an earlier release line first, but that just
> points to a need for more releases.
> On Fri, Jun 2, 2017 at 10:18 PM, Christopher <> wrote:
>> On Fri, Jun 2, 2017 at 2:15 PM Josh Elser <> 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?

View raw message