> I'm -1 (non-binding) on weakening our compatibility promises. The more we can isolate our users from the impact of changes upstream the better.
We can't though in general. Making compatibility promises we can't keep because our upstreams don't (see the dependencies section of Hadoop's compatibility guidelines) is ultimately an untenable position. *If* we had some complete dependency isolation for MapReduce and coprocessors committed then this could be a different conversation. Am I misstating this? In this specific instance we do have another option, so we could defer this to a later time when a really unavoidable dependency change happens... like a Guava update affecting HDFS. (We had one of those before.) We can document the Jackson classpath issue with Hadoop >= 2.6 and provide remediation advice in the troubleshooting section of the manual. I would be disappointed to see a VOTE thread. That means we failed to reach consensus and needed to fall back to process to resolve differences. Why don't we do the doc update and call it a day? On Thu, Mar 12, 2015 at 7:32 PM, Sean Busbey <bus...@cloudera.com> wrote: > On Thu, Mar 12, 2015 at 1:20 PM, Enis Söztutar <enis....@gmail.com> wrote: > > > This is good discussion, but I would like to reach a consensus and move > on > > with HBASE-13149. > > > > My conclusion from the thread is that we cannot be realistically expected > > to keep dependency compat between minor versions because of lack of > shading > > in HBase and Hadoop, and our dependencies are themselves not semver, and > we > > cannot promise more than our dependencies promise. > > > > So I would like to formally drop support for dependency compat between > > minor versions as defined in > > https://hbase.apache.org/book.html#hbase.versioning. We can reintroduce > > later when we have better isolation/guarantees. In the mean time, we can > > move on. > > > > > I'm -1 (non-binding) on weakening our compatibility promises. The more we > can isolate our users from the impact of changes upstream the better. If > our dependencies aren't semver it's all the more reason for us to be > disciplined about 1) accepting them as exposed in the first place and 2) > changing them. > > This is the first problem that has presented itself in the face of the > restrictions we adopted as a community. I don't care for the precedent of > us solving it by weakening those promises. For one thing, it reinforces > messaging from vendors that folks need them to protect against choices > individual projects make. > > If I have a solution that works to separate us from Hadoop when running on > YARN in Hadoop 2.6+ before 1.1 is ready, can we keep our compat at the > current strength? Some other deadline? AFAIK, we have no direct need for > Jackson 1.9. > > > > > The PMC has approved the compat guide, but I am not sure whether we need > a > > VOTE thraed. What do you guys think? > > > > > My main concern with not having a VOTE thread is that some PMC members > might be more likely to pay attention to the matter if there's a VOTE, so a > DISCUSS thread might only show consensus among a subset. > > Changes to the promises we make downstream are a big deal, so I'd prefer to > err on the side of more participation. I'd also really like that VOTE > thread to include user@hbase, since this impacts downstream users more > than > us directly. > > -- > Sean > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
