But I don't see patch version releases generally. Right? So if you look at release history you'd expect new minors not new patches.
> On Jul 5, 2016, at 11:32 AM, Nick Dimiduk <ndimi...@apache.org> wrote: > > 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) >>
