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 <md...@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 <ctubb...@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 <bus...@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 <mwa...@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 <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. > > > >>> > > > >> > > > > > > > > > > > > -- > > > busbey > > > > > >