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 <mwa...@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 <ctubb...@apache.org> wrote: > >> On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey <bus...@cloudera.com> wrote: >> >> > On Mon, Jun 5, 2017 at 11:12 AM, Christopher <ctubb...@apache.org> >> wrote: >> > > On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey <bus...@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. >> >
