I would really like to get maintenance releases. Release cadence for minor releases and patch releases should be orthogonal in theory, but we are all human and there are only so many hours in a day. I would opt for doing actual maintenance releases rather than more frequent minor releases. Having smaller changes is definitely good to get a release out the door, but hbase/phoenix is a database. Nobody on their right mind updates their database every month.
+1 for Lars as always. Enis On Tue, Jul 5, 2016 at 6:51 PM, Andrew Purtell <andrew.purt...@gmail.com> wrote: > Stating it another way: As far as I know, all bugs found in the 4.7.0 > release are going to be fixed with 4.8.0, not a 4.7.1, and there's nobody > planning to maintain a 4.7.x line of releases. It was this way with 4.6.0 > as well, all bug fixes for problems in 4.6.0 were put in the 4.7.0 release, > not a 4.6.1 patch release. I don't think there will ever be a 4.6.x patch > release. > > Like Nick asked, with a monthly release cadence do we see this changing? > > Let me put forward this thought: It will be easy to hit a monthly release > cadence if we treat bug fixes and bigger works like transactions (4.7) and > local index reimplementations (4.8) differently. We branch appropriately > for making patch releases but don't take advantage of them. That's easy to > change. Commit bug fixes to development heads and maintenance/release > branches both. Cut releases from the maintenance branches monthly. Simple. > When the time comes, just do it. Meanwhile as the bigger things fully bake > do a new minor or even major rev to release them. Bug fixes will not have > been held up no matter how long it may have taken for next new feature X to > bake. In exchange, there will be point releases to make. The HBase "branch > RM" model could be helpful for distributing that work. > > > > On Tue, Jul 5, 2016 at 1:27 PM, Andrew Purtell <andrew.purt...@gmail.com> > wrote: > > > 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) > > >> > > >
