All good discussions.
IMHO what matters most initially is to get more frequent and smaller releases.
The effect is a more steady commit stream, more stable releases, and earlier
access to bugfixes (and features) for users.
The patch/minor cadence will likely emerge a function of that, we'll see how
the community feels. Kinda like it happened with HBase during 0.94 - or maybe
it won't, and that's fine too.
(The discussion of maintaining patch releases is orthogonal to release
frequency... Personally I am a fan of at least a few patch releases per minor
release, but it needs enough RMs to sign up for their maintenance and agreement
from the community over all)
-- 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)
>
