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 21:01:42 GMT
My examples in my last email assume that 1.8 is the first LTS branch.  I
think this makes sense as 1.8 should be the last 1.x release.

On Mon, Jun 5, 2017 at 4:52 PM Mike Walch <mwalch@apache.org> wrote:

> 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