accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Walch <mwa...@apache.org>
Subject Re: [DISCUSS] Question about 1.7 bugfix releases
Date Mon, 05 Jun 2017 20:52:17 GMT
This debate seems to come up frequently and the viewpoints expressed seem
to represent one of two groups of Accumulo users:

1. conservative, enterprise users that want to avoid upgrades and want
long-term support.
2. early adopters and developers that want frequent minor releases as they
are willing to upgrade and don't care about long-term support.

I think our goal should be keep both groups happy as enterprise users
typically pay the bills and early adopters/developers help test out new
releases and features.

Currently, we advertise a 1.6, 1.7, and 1.8 release on our downloads page.
If I was an enterprise user, I would not know which release to use or
upgrade to.  I think we should instead identify certain minor releases as
long-term support releases (LTS) (like Ubuntu) and push enterprise users to
use them.

Our website and downloads push could advertise the latest release and the
latest LTS release.  This could allow us to minimize the number of
maintenance branches by only supporting the latest minor release branch and
latest LTS branch.  For example, if our latest release is 2.2.0, we can
drop support for the 2.0 & 2.1 branches but support new bugfix releases on
the 2.2 and 1.8 branches.

If the 2.2 branch is identified as the next LTS branch, we could develop an
easy upgrade script for enterprise users to go directly from 1.8 to 2.2
(skipping 2.0, 2.1).

On Mon, Jun 5, 2017 at 3:12 PM Christopher <ctubbsii@apache.org> wrote:

> On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey <busbey@cloudera.com> wrote:
>
> > On Mon, Jun 5, 2017 at 11:12 AM, Christopher <ctubbsii@apache.org>
> wrote:
> > > 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.
> > >
> >
> > In my limited experience, when ASF projects don't reliably make
> > maintenance releases, enterprise customers turn to vendors to provide
> > a source of conservative updates. Phrased another way, it's a thing
> > that I see pointed to for why a decision maker might pick a vendor
> > "powered by" an asf project rather than asf blessed releases.
> >
> >
> I've seen that, too. Are you suggesting that's a problem?
>
> I'm interested in providing more frequent releases on fewer maintenance
> branches. But, if a vendor wants to provide an alternate upgrade path to
> fill a specific need for users with special requirements for earlier
> branches, I think that's fine.
>

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