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 19:12:11 GMT
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