Oh as you know, I am a very big fan of clearly defined patch/minor/major
compatibility.I'd love to have something like what we now have for HBase for
Phoenix as well. (could view it as debt paid forward if we want to really
consider merging the PMCs :) )
-- Lars
From: Nick Dimiduk <ndimi...@apache.org>
To: phoenix-dev <dev@phoenix.apache.org>
Sent: Tuesday, July 5, 2016 11:32 AM
Subject: Re: [DISCUSS] RM for next release
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)
>
