+1 Caveat that that 4.1, 4.2 lines should probably get their own branches.
------------------- Jesse Yates @jesse_yates jyates.github.com On Mon, Feb 10, 2014 at 3:50 PM, James Taylor <jamestay...@apache.org>wrote: > Sure, 4.0 is fine. I think we can just tag our minor and point releases > instead of creating branches for them. > > > On Mon, Feb 10, 2014 at 3:41 PM, Jeffrey Zhong <jzh...@hortonworks.com > >wrote: > > > > > James, how do you think the branch name 4.0 over 4.0.0? It mostly depends > > on the naming convention. 4.0 seems better > > unless in the future we have branch like 4.0.1(or 4.0.##) > > > > > If you set up a job building against HBase trunk snapshots (and > > HBase remembers to publish those then > > > Jenkins can catch any incompatibilities accidentally introduced > > going forward. > > > > > > I like the above idea so that we can catch interface changes as earlier > as > > possible. > > > > > > On 2/10/14 2:33 PM, "James Taylor" <jamestay...@apache.org> wrote: > > > > >+1. That's a very good idea, Enis - for HBase 1.0 if possible. > > > > > > > > >On Mon, Feb 10, 2014 at 2:28 PM, Enis Söztutar <enis....@gmail.com> > > wrote: > > > > > >> Forgot to mention, there was some discussion about filter / > coprocessors > > >> versus plugins. It seems that coprocessors are doing both more > > >>user-facing > > >> database trigger kind of functionality + some plugging into Hbase > > >>internals > > >> functionality. I think longer term, we should define different > > >>interfaces > > >> for some pluggable functionality (see recent StorageEngine, > Compaction, > > >> Flush, HLog, etc) and keep coprocessors more simple. This was plugins > > >>would > > >> be the supported way to extend HBase, and the interfaces would be more > > >> stable. > > >> > > >> > > >> On Mon, Feb 10, 2014 at 2:23 PM, Enis Söztutar <enis....@gmail.com> > > >>wrote: > > >> > > >> > Awesome work Jeffrey. > > >> > > > >> > Should we name the branch 4.0, instead of 4.0.0? > > >> > > > >> > It would be good to have a list of methods used by Phoenix to be > > >> > identified and tagged in HBase so that at least future changes are > not > > >> > completely random. We might start with annotation > > >> > InterfaceAudience.LimitedPrivate, so that HBase devs will be more > > >> careful. > > >> > However, we should also try to make Phoenix not so far-reaching into > > >> HBase > > >> > internals as well. > > >> > > > >> > Enis > > >> > > > >> > > > >> > On Mon, Feb 10, 2014 at 2:16 PM, Andrew Purtell < > apurt...@apache.org > > >> >wrote: > > >> > > > >> >> On Mon, Feb 10, 2014 at 2:07 PM, James Taylor < > > jamestay...@apache.org > > >> >> >wrote: > > >> >> > > >> >> > Mujtaba - would it be > > >> >> > feasible to setup Jenkins builds for this branch as well? > > >> >> > > > >> >> > > >> >> Or, HBase 0.98 is really close to HBase trunk still. If you set up > a > > >>job > > >> >> building against HBase trunk snapshots (and HBase remembers to > > >>publish > > >> >> those...) then Jenkins can catch any incompatibilities accidentally > > >> >> introduced going forward. > > >> >> > > >> >> -- > > >> >> Best regards, > > >> >> > > >> >> - Andy > > >> >> > > >> >> Problems worthy of attack prove their worth by hitting back. - Piet > > >>Hein > > >> >> (via Tom White) > > >> >> > > >> > > > >> > > > >> > > > > > > > > -- > > CONFIDENTIALITY NOTICE > > NOTICE: This message is intended for the use of the individual or entity > to > > which it is addressed and may contain information that is confidential, > > privileged and exempt from disclosure under applicable law. If the reader > > of this message is not the intended recipient, you are hereby notified > that > > any printing, copying, dissemination, distribution, disclosure or > > forwarding of this communication is strictly prohibited. If you have > > received this communication in error, please contact the sender > immediately > > and delete it from your system. Thank You. > > >
