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. -- busbey
