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.
