Personally I'd be in favor of 4.0.0 as this conveys the fact that we do semantic versioning. As usually I do not feel strongly about this.
-- Lars ________________________________ From: James Taylor <[email protected]> To: "[email protected]" <[email protected]> Sent: Monday, February 10, 2014 3:50 PM Subject: Re: Branch 4.0.0 is created for Phoenix on HBase0.98 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 <[email protected]>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" <[email protected]> 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 <[email protected]> > 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 <[email protected]> > >>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 <[email protected] > >> >wrote: > >> > > >> >> On Mon, Feb 10, 2014 at 2:07 PM, James Taylor < > [email protected] > >> >> >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. >
