If we were to launch a long term stable release expected to produce monthly maintenance releases for, potentially, years, I would sign up for maintaining that branch-set. This is what I have been doing over in HBase with 0.98.
> On Jul 7, 2016, at 1:50 AM, James Taylor <jamestay...@apache.org> wrote: > > It's good we're having this discussion. I think the crux of the issue is > lack of people to step up as RM for branch. Each minor release, we create > the branch, so everything is in place to do it. A secondary, related issue > is the number of branches that need to be kept up to date: 4 branches (1 > per supported HBase version) * (number of patch release branches) becomes > unwieldy fast. If we can drop support for everything except HBase 1.2, that > would help make it more feasible (but we'd still need an RM per minor > release branch). But I think the user community would likely be looking for > patch release for 0.98 branch most of all. > > Thanks, > James > >> On Wed, Jul 6, 2016 at 11:57 PM, Enis Söztutar <e...@apache.org> wrote: >> >> 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) >>
