We already support multiple release code lines via branch-per-hbase version.
On Tue, Jul 5, 2016 at 10:05 AM, Andrew Purtell <apurt...@apache.org> wrote: > Will under a new monthly cadence the project still produce new minor > versions at every release until the community decides to do a major > increment, then continue with minors again? > > Or is the plan as Nick wonders to support released minor versions longer, > via patch versions? If so, I suppose this would mean active maintenance of > multiple code lines, and, if so, are we considering or should we consider > the HBase "branch RM" style management for that? > > > On Tue, Jul 5, 2016 at 9:53 AM, Nick Dimiduk <ndimi...@apache.org> wrote: > > > Is this thread to discuss Lars for RM, for moving to a monthly release > > cadence, or propose specific JIRAs for the next release? One the above: > > > > +1 for Lars, he knows how to make releases happen :) > > > > Is this monthly cadence for patch releases? So far this community hasn't > > seen fit to make patch releases, so I'm wondering what's changed now. Are > > we thinking the rate of change in the product has slowed/stabilized and > now > > we're going to support released versions longer? Have we decided on > policy > > re: what makes a change suitable for a patch release vs. the next minor? > > > > Re: these tickets, those all look like good improvements and fixes to get > > shipped. Hopefully the last two would qualify as patch release material. > > > > On Sat, Jul 2, 2016 at 12:16 AM, James Taylor <jamestay...@apache.org> > > wrote: > > > > > Lars has bravely volunteered to be our RM for our next release with an > > aim > > > to help us get on a monthly release cadence. Big +1 from me. We have a > > few > > > features teed up on the encodecolumns branch: > > > > > > PHOENIX-1598 Encode column names to save space and improve performance > > > PHOENIX-2565 Store data for immutable tables in single KeyValue > > > > > > These have both been implemented in a b/w compatible manner. Existing > > > tables would continue to work as-is and new tables would take advantage > > of > > > these new formats. > > > > > > A couple of other important JIRAs that I know about are: > > > > > > PHOENIX-2995 Write performance severely degrades with large number of > > views > > > PHOENIX-2724 Query with large number of guideposts is slower compared > to > > no > > > stats > > > > > > Hopefully these can make it in, but it'd be up to the digression of the > > RM, > > > of course. > > > > > > Thanks, > > > James > > > > > > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) >
