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 22:52:54 GMT
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