accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc <phroc...@apache.org>
Subject Re: [DISCUSS] Question about 1.7 bugfix releases
Date Tue, 06 Jun 2017 16:14:44 GMT
I'm not sure it would solve Bob's concern of having more "soak time," but
we could clarify that 1.8.1 is Stable.

The linux kernel makes the releases very clear:  https://www.kernel.org/

Do you think that presenting 1.8.1 as the stable branch will help? I see
the Releases dropdown shows 1.8.1 as 'Latest'. In my opinion that doesn't
serve 1.8.1 very well.

Some will believe it's too new to try regardless of nomenclature, but
personally I see Latest and think "let someone else try it first."

On Tue, Jun 6, 2017 at 12:02 PM, Mike Drob <mdrob@apache.org> wrote:

> As a specific example of folks looking at 1.7.3 as stable and seeing 1.8.x
> as unstable, we have a current thread on the dev list -
> https://lists.apache.org/thread.html/6e83fc644437c41ace5847d1cd5622
> f8174f7e0f8dfd1a30a8fd7116@%3Cdev.accumulo.apache.org%3E
>
> Right or wrong, that's the way things are right now.
>
> On Mon, Jun 5, 2017 at 5:52 PM, Christopher <ctubbsii@apache.org> wrote:
>
> > The way I think about it, the 1.x line is our LTS release, not a specific
> > minor release within 1.x (at least, since we starting guaranteeing
> > backwards compatibility). This is because even in LTS models like Ubuntu
> or
> > RHEL, new features are added if they are backwards-compatible. This is
> why
> > I think we're possibly not doing a good enough job at declaring that the
> > newer minor releases in 1.x can/should be upgraded to once we think
> they're
> > stable. This is a bit like the RHEL model. The "LTS" release is RHEL 7,
> and
> > maintenance effectively stops on 7.2 once 7.3 is released, because the
> > patch process becomes "update to 7.3". Most people wouldn't consider an
> > upgrade from 7.2 to 7.3 a risky update, because of the delivery mechanism
> > (patch releases... updates to specific RPMs... are delivered the same way
> > as minor releases: yum update). So, in a sense, I think the reason we're
> > having this discussion is because we don't have a good "delivery
> mechanism"
> > to ensure upgrade confidence to the next minor release. The analogy isn't
> > perfect, but hopefully that gives a hint at how I'm thinking about "LTS".
> > Major releases seem to be a natural demarcation point for me for the
> "LTS"
> > concept.
> >
> > What it really comes down to for me, is "what is the upgrade path?" And,
> I
> > think our current model of having so many, sometimes inconsistent (due to
> > timing of releases), upgrade paths isn't very efficient, is potentially
> > confusing, and I worry that it's inhibiting the goal that we all seem to
> > agree needs to happen: more frequent patch releases.
> >
> > Currently, our de facto support mechanism is the "last 2 minor releases"
> > (dev minus 1, dev minus 2).
> > I opened this conversation suggesting that, perhaps, it is better to
> switch
> > to "last 1 minor releases (once stable)" (dev-1).
> > A middle-ground might be: "last 1 minor release (once stable) for routine
> > patches + last 2 minor releases for critical or on-demand patches".
> (dev-1,
> > dev-2*).
> >
> > The way that middle ground might work is: we clean up JIRA so that we
> don't
> > have to keep bumping issues which aren't being worked on (dev-2). Instead
> > of starting patches at (dev-2), merging into (dev-1), and then into
> > (dev/master), we start at (dev-1). If it's a critical issue, we'll
> probably
> > want to start at (dev-2). If somebody contributes specifically because
> they
> > need/want something fixed in (dev-2), we encourage them to do so, and
> take
> > the opportunity to on-board a new committer as that patch is applied and
> > released. We won't say "no" to (dev-2) patches and releases, but we don't
> > have to require every routine patch start that far back, either. Patches
> > can always be backported to (dev-2) on-demand if somebody is willing to
> > champion it.
> >
> >
> > On Mon, Jun 5, 2017 at 5:43 PM Sean Busbey <busbey@cloudera.com> wrote:
> >
> > > We should remove the 1.6 stuff, since it went EOM back in September
> 2016.
> > >
> > > FWIW, all the folks I have visibility into are running either 1.4 (I
> > > know... :( ), 1.6, or 1.7. Granted this is biased by the fact that the
> > > vast majority (but not all) are relying on something "Powered By"
> > > those apache release versions and the provider of those "powered by"
> > > bits don't offer anything based on 1.8.
> > >
> > > I like the idea of having a LTS branch. Something analogous to what
> > > I've seen other communities do by designating a "current stable"
> > > release line that's expected to keep getting updates for longer. It
> > > makes it easy to guide most folks towards using that version.
> > >
> > > Another possibility is to change how we structure application of fixes
> > > so that every developer doesn't have to deal with every active branch.
> > > Apache Avro, for example, historically just had everyone patch to the
> > > trunk branch and left it up to release managers to cherry pick back to
> > > active release lines.
> > >
> > > On Mon, Jun 5, 2017 at 4:01 PM, Mike Walch <mwalch@apache.org> wrote:
> > > > 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.
> > > >>>
> > > >>
> > >
> > >
> > >
> > > --
> > > busbey
> > >
> >
>

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