Seems I misunderstood the conclusion of this discussion and pushed
prematurely HBASE-13339 (and perhaps HBASE-13149). On that ticket, Lars
states
I don't recall that we agreed on this. Should be in trunk (2.0) no doubt.
There was a longer discussion about 1.1 and I seem to recall
that we said
A second thought on this. I wonder how it is going to work. The test suite
probably will run with old Jackson version with the compile. We will ship
what we don't test with?
Whatever we do seem to imply similarly small risk ...
On Apr 25, 2015 8:02 PM, Nick Dimiduk ndimi...@gmail.com wrote:
I'm
I spoke with a couple of our HDFS folks on Friday, they sound confident
that 2.7.1 will be considered production-stable. I think we can try bumping
master to 2.7.1 when it's out.
On Fri, Apr 24, 2015 at 10:03 AM, Sean Busbey bus...@cloudera.com wrote:
On Fri, Apr 24, 2015 at 11:53 AM, Elliott
I'm game for giving it a shot if we can build some confidence it won't
cause other issues. However given we're moving to Hadoop 2.6 I think we've
already relaxed the constraints and this won't buy us much. More trouble
than it's worth?
On Saturday, April 25, 2015, Jerry He jerry...@gmail.com
This is an interesting idea from Sean.
On the Jackson thing, are folks opposed to compiling with the current
older
version and then packaging the newer version? That would make sure we
don't
start using 1.9 features in a way that would prevent downstream users from
downgrading to 1.8, which
On Thu, Apr 23, 2015 at 6:39 PM, Enis Söztutar enis@gmail.com wrote:
I would be in favor of going 2.6.0 and jackson upgrade in 1.1.
I am also +1 bumping to Hadoop 2.6.x and Jackson 1.9.x in HBase 1.1.0. This
seems like the most practical solution to the problems outlined here. Let
me
On Fri, Apr 24, 2015 at 10:25 AM, Sean Busbey bus...@cloudera.com wrote:
On Fri, Apr 24, 2015 at 12:21 PM, Stack st...@duboce.net wrote:
On Fri, Apr 24, 2015 at 9:21 AM, Josh Elser josh.el...@gmail.com
wrote:
Cool, it seems that we have consensus. Let me try to give a patch since
you
Is 2.7.1 going to have that not for production tag or was that tag just
because of the issues found late in the cycle that are now fixed?
On Fri, Apr 24, 2015 at 9:50 AM, Sean Busbey bus...@cloudera.com wrote:
On Thu, Apr 23, 2015 at 7:34 PM, Nick Dimiduk ndimi...@gmail.com wrote:
On Thu,
Cool, it seems that we have consensus. Let me try to give a patch since
you all were nice enough to entertain me with a good discussion on the
matter!
https://issues.apache.org/jira/browse/HBASE-13554
Enis Söztutar wrote:
+1 to working toward semver. Is there any documentation that we would
On Thu, Apr 23, 2015 at 7:34 PM, Nick Dimiduk ndimi...@gmail.com wrote:
On Thu, Apr 23, 2015 at 4:13 PM, Stack st...@duboce.net wrote:
Does this 'admission' help with the which-hadoop thread too?
Right -- working toward semver.
Are we now at liberty to bump to 2.6 or 2.7 even for
On Fri, Apr 24, 2015 at 9:21 AM, Josh Elser josh.el...@gmail.com wrote:
Cool, it seems that we have consensus. Let me try to give a patch since
you all were nice enough to entertain me with a good discussion on the
matter!
https://issues.apache.org/jira/browse/HBASE-13554
Thanks for
On Fri, Apr 24, 2015 at 11:53 AM, Elliott Clark ecl...@apache.org wrote:
Is 2.7.1 going to have that not for production tag or was that tag just
because of the issues found late in the cycle that are now fixed?
From reading from hadoop lists, I'm not sure. Including the non-production
tag
Anyone disagree with the point of view put forward by Josh and Sean?
On Wed, Apr 22, 2015 at 10:35 AM, Josh Elser josh.el...@gmail.com wrote:
Andy -- I understood your intent, but thanks for clarifying. (as well as
taking the time to break this discussion out in the first place). I agree
+1 to the proposal.
The problem is that we have a very big API surface especially with the
coprocessors included in the report. Even simple bug fixes can introduce
protected or public methods to base classes, which makes patch releases
very hard to maintain. I would not want to spend the effort
Why don't we just focus development after a minor release on the next minor
release instead of the next patch release?
We could limit backports to the patch releases to critical bugs, which
would cut down on how often someone has to deal with the pain of making
sure we don't add to public APIs.
Enis Söztutar wrote:
+1 to the proposal.
The problem is that we have a very big API surface especially with the
coprocessors included in the report. Even simple bug fixes can introduce
protected or public methods to base classes, which makes patch releases
very hard to maintain. I would not
I agree w/ the Enis characterization (so we need the callout on semvar) but
think we should practice what Seans says (patch is bug fixes only).
St.Ack
On Thu, Apr 23, 2015 at 1:31 PM, Sean Busbey bus...@cloudera.com wrote:
Why don't we just focus development after a minor release on the next
So we like semver, not we use semver?
Just want to make sure we're all on the same page (or find out if not).
On Thu, Apr 23, 2015 at 2:59 PM, Enis Söztutar e...@apache.org wrote:
Then let's get Andrew's proposal committed:
+ APIs available in a patch version will be available in all later
We also do it, so that users see less of This was in 0.98, but how come
it is not in 1.0.x. I think we will get substantially better over time.
It will. Eventually we will EOL 0.98
In the meantime we could clarify how 0.98 relates to later releases now
that releases 1.0.0 and up are being more
I'm fine with us adding methods to public APIs in patch releases so long as
we stop claiming to follow semver. We can say we take the principles of
semver as inspiration. This would reflect the current state of the world
WRT 1.0.1 and would still give us a reason keep the narrower definition of
On Thu, Apr 23, 2015 at 1:31 PM, Sean Busbey bus...@cloudera.com wrote:
Why don't we just focus development after a minor release on the next minor
release instead of the next patch release?
We could limit backports to the patch releases to critical bugs, which
would cut down on how often
On Thu, Apr 23, 2015 at 3:08 PM, Andrew Purtell apurt...@apache.org wrote:
So we like semver, not we use semver?
and Sean's
No longer claiming semver would also have the added benefit of making it for
me to easier to explain our compatibility promises to people.
Yeah, 'we like semvar'/'we
Stack wrote:
On Thu, Apr 23, 2015 at 3:08 PM, Andrew Purtellapurt...@apache.org wrote:
So we like semver, not we use semver?
and Sean's
No longer claiming semver would also have the added benefit of making it for
me to easier to explain our compatibility promises to people.
Yeah,
+1 as well.
On Apr 23, 2015, at 4:36 PM, Josh Elser josh.el...@gmail.com wrote:
Stack wrote:
On Thu, Apr 23, 2015 at 3:08 PM, Andrew Purtellapurt...@apache.org wrote:
So we like semver, not we use semver?
and Sean's
No longer claiming semver would also have the added
On Thu, Apr 23, 2015 at 4:13 PM, Stack st...@duboce.net wrote:
Does this 'admission' help with the which-hadoop thread too?
Right -- working toward semver.
Are we now at liberty to bump to 2.6 or 2.7 even for branch-1.1? I still
have Karthik's offer to roll a 2.5.3 with the HDFS issue
On Thu, Apr 23, 2015 at 5:08 PM, Andrew Purtell apurt...@apache.org wrote:
So we like semver, not we use semver?
Just want to make sure we're all on the same page (or find out if not).
+1 from me.
I'd prefer we not make the statements about binary compat for downgrading
because it's
+1 to working toward semver. Is there any documentation that we would
like to clarify in the book given this enlightenment?
I would be in favor of going 2.6.0 and jackson upgrade in 1.1.
Enis
On Thu, Apr 23, 2015 at 5:34 PM, Nick Dimiduk ndimi...@gmail.com wrote:
On Thu, Apr 23, 2015 at 4:13
[Subject changed]
On Tue, Apr 21, 2015 at 8:47 PM, Josh Elser josh.el...@gmail.com wrote:
I was a little surprised when I noticed method additions to
InterfaceAudience.Public annotated classes. This means that a user could
write code against 1.0.1 that would not work against 1.0.0 which seems
I think these changes are Okay.
On Wed, Apr 22, 2015 at 9:29 AM, Andrew Purtell apurt...@apache.org wrote:
[Subject changed]
On Tue, Apr 21, 2015 at 8:47 PM, Josh Elser josh.el...@gmail.com wrote:
I was a little surprised when I noticed method additions to
InterfaceAudience.Public
While I can understand the desire to want to add things, I do think it
makes things harder for users to reliably write code against versions of
HBase which (by their view) should be completely compatible with one
another.
Take this extremely hypothetical situation: I'm new to HBase and start
I'd much rather we stick with the definitions used in Semantic Versioning.
Our use is already confusing enough given our matrix of compatibilities
that don't get major version for breaking protections.
We've previously discussed how we'll do additional minor releases when
there's sufficient
Just to clarify something, I've proposed edits that clarify the de-facto
practice, since additional methods are turning up in patch releases, but am
not taking a position.
So far we don't have consensus.
+ HBase uses Semantic Versioning for its release versioning with a caveat
that methods and
Andy -- I understood your intent, but thanks for clarifying. (as well as
taking the time to break this discussion out in the first place). I
agree with your assessment.
re: Sean's comments, if it wasn't clear by me asking in the first place,
I also think sticking as close as possible to
33 matches
Mail list logo
