accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Question about 1.7 bugfix releases
Date Mon, 05 Jun 2017 16:12:02 GMT
On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey <busbey@cloudera.com> 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.
>
>
I agree that occurs, but I also think that such rules in enterprises don't
exist in a vacuum. They exist in the context of what the project itself is
doing. Choosing to upgrade to a new maintenance release is only an option
when the upstream project is still producing maintenance releases. Since
that's at the core of what this discussion is about, the question becomes
something like "If we do this, will we be encouraging [enterprise and
other] users to use the latest minor.patch release on their next upgrade
cycle, or are we discouraging them from upgrading at all?" I don't know the
answer, but if it's the latter, the next question is "Can we correct for
any misperceived risks by better communicating what we know about upgrade
risks to newer minor versions?" I don't know the answer to that question,
either.

In my experience with my "enterprise" customers, the reluctance to upgrade
seems to apply equally to all versions. I recently provided support to
somebody still running 1.5.0, in spite of the 1.5 line being on 1.5.4 and
*very* EOL, because of reluctance to upgrade.



> 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.
>
>

Agreed. We need more releases. What I'm thinking is that more releases
would be easier for us to do if we drop maintenance branches for minor
versions which have a clear upgrade path to a stable newer minor release.
I'm also wondering if we can reduce confusion on users, and encourage
upgrading, by reducing the number of possible upgrade paths.


>
>
> On Fri, Jun 2, 2017 at 10:18 PM, Christopher <ctubbsii@apache.org> wrote:
> > On Fri, Jun 2, 2017 at 2:15 PM Josh Elser <elserj@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?
> >> >
> >>
>
>
>
> --
> busbey
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message