For the number of patch release, I think it depends on the speed we add new features. The more features contained in a minor release, the more patch releases we need. Of course a responsible RM will also trigger more releases.
What I want to say is, we do not need to set a hard limit on the interval between patch releases which may spend too much time for the RM, or force users to upgrade to a new minor version because we will not make new patch release for a previous minor version even it contains several critical bugs since minor release could still break things according to our compatible matrix. Just release on demand. I believe for the coming 2.0 and 2.1 release line, we will have (kinda) lots of fixes even after the final minor release since there are lots of new features. It will be strange that we just release a (kinda) buggy version and then tell users we will not fix it any more, just upgrade to new minor versions... And I think making releases should be part of the work of all PMCs. Honestly say I'm not doing well in this area, and so do lots of others PMCs. Will try to take more responsibility in the future. Thanks. 2018-03-09 1:30 GMT+08:00 Andrew Purtell <andrew.purt...@gmail.com>: > The Phoenix project typically releases new minors. Patch releases are > rare. This used to be our model too before 1.0. (For the 0.x.y versions > mentally drop the "0.") > > Users don't seem to care. > > I do think there is appetite for one or two long term stable code lines. > Right now that's branch-1.2. As long as we have an interested and engaged > RM making regular releases we can give their work the LTS designation. When > they move on more move up, we reevaluate. > > > From logistic perspective, we are moving from a model where few people > are locked in for long time (4-5 RMs locked in for ~10 patch releases) to a > model where more people are locked in for less time (more minor releases -> > more RMs, but hopefully only 4-5 patch releases) with 2-3 CT (care takers). > > Yes, that's the idea. > > As branch-1 RM I would probably make new minor releases myself every 3-6 > months if we didn't have other volunteers. The period between minors will > get longer as development activity slows and more activity moves to 2.0 and > up. Unless we had a volunteer maintaining a minor branch they would be > effectively retired once the new minor came out and had one or two patch > releases, maybe, to fine tune. > > > > On Mar 8, 2018, at 3:03 AM, Apekshit Sharma <a...@cloudera.com> wrote: > > > > So to sum up my understanding of the idea: > > - More minor/major releases, less patch releases > > - From logistic perspective, we are moving from a model where few people > > are locked in for long time (4-5 RMs locked in for ~10 patch releases) > to a > > model where more people are locked in for less time (more minor releases > -> > > more RMs, but hopefully only 4-5 patch releases) with 2-3 CT (care > takers). > > > > Just trying to put some numbers to make sure all are on same page. > > > > We can try it. Idea sounds good to me. > > > > @andrew: Is there any other community which follows this/similar pattern? > > How's their experience? Do users like/hate more minor releases? > > > > -- Appy > > > > > > On Thu, Mar 8, 2018 at 8:02 AM, Andrew Purtell <apurt...@apache.org> > wrote: > > > >>> > >> β > >> For eg. Andrew will caretake branch-1.4, Stack will caretake branch-2.0 > >> > >> Not as I originally proposed. In this example, Andrew will caretake > >> branch-1 and Stack will caretake branch-2. Andrew and Stack will be > making > >> more minor release branches more often and patch releases will become > less > >> frequent. For example, I'm going to be done with branch-1.4 in six > months > >> and on to branch-1.5. (Hypothetically.) Anyone is welcome to RM those > >> branch-x.y. As long as someone is actively RMing branch-x.y it stays > alive. > >> That's how we'd come to a consensus on what is long term stable. > >> > >> > >>> On Wed, Mar 7, 2018 at 5:55 PM, Apekshit Sharma <a...@cloudera.com> > wrote: > >>> > >>> I like the thought, continuing to brainstorm.... > >>> In this method, the following holds true, right? > >>> - Care taking "branch-X.Y" will require least effort and will by > default > >>> fall onto the shoulders of RM for X.Y version. > >>> ββ > >>> For eg. Andrew will caretake > >>> branch-1.4, Stack will caretake branch-2.0, and so on. > >>> - Care taking "branch-X" will require a bit more effort and it's > >> uncertain > >>> how to assign one to such branches. > >>> One way is, whoever will do the next minor release can own it. But the > >>> caveat in that is, > >>> a) It's hard to find RMs as such, this may make it more difficult > since > >>> one will have to own up the task much ahead in advance. Or, the effect > >>> could be opposite, since this way gives more heads up for carrying out > RM > >>> responsibilities. Would be certainly interesting to see how it works > out. > >>> b) For branch-1 which might be close to finish, there's uncertainty - > >>> assign care taker but no future release (wasted effort?), OR, no care > >> taker > >>> until we decide that there will be future release (more like status > >>> quo). We can make the decision when we are at the fork. For now, seems > >> like > >>> we have one who's willing to take care of branch-1 to shepherd it > towards > >>> 1.5.0....smile. > >>> > >>> Other way is, once can just caretake a branch without singing up to do > >>> the next release. > >>> I don't think we have to choose one way or another (in fact, we might > >> not > >>> have the luxury) and instead, can go with the flow (i.e. as > contributions > >>> show up). > >>> > >>> - Care taking for "master": The most onerous task since almost > everything > >>> goes in it - all patches, new features, bug fixes, test breaking > changes, > >>> etc. Defining 'care taking' of this branch will be a bit more > difficult. > >>> Might be too big for single person, maybe round robin the task among > >>> committers/contributors (generates another opportunity for contributors > >> to > >>> sparkle and become committers)? > >>> Unless this one is solved, we are not rectifying the problem mentioned > by > >>> Stack previously - "...avoiding the hell that was 2.0.0 where its taken > >>> near on a year to stabilize (first alpha was last year) because it has > >> over > >>> 5k JIRAs in it". > >>> > >>> To end on positive note, i volunteer to care take branch-2 once 2.0 GA > is > >>> out. > >>> > >>> -- Appy > >>> > >>>> On Thu, Mar 8, 2018 at 6:10 AM, Mike Drob <md...@apache.org> wrote: > >>>> > >>>> If somebody volunteers to be the caretaker for 1.5.0, is there an > >>> implicit > >>>> expectation that they would take on the responsibilities for branch-1 > >> as > >>>> well? > >>>> > >>>>> On Wed, Mar 7, 2018 at 5:12 PM, Stack <st...@duboce.net> wrote: > >>>>> > >>>>> (Moving discussion to DISCUSSION thread from "NOTICE: made branch-2.0 > >>>>> from..." -- my fault for starting it in wrong place) > >>>>> > >>>>> A while back, Andrew made a PROPOSAL for 'branch RM's [1]. I like > >> this > >>>>> suggestion. I see it as a means of avoiding the hell that was 2.0.0 > >>> where > >>>>> its taken near on a year to stabilize (first alpha was last year) > >>> because > >>>>> it has over 5k JIRAs in it; RMs can help keep their branch tidy and > >>> free > >>>> of > >>>>> flotsam. > >>>>> > >>>>> Andrew added more to his notion of 'branch RM' over in the NOTICE > >>>> thread. I > >>>>> repeat it below: > >>>>> > >>>>> "βFor a while leading up to 1.4.0 I was effectively the branch-1 RM > >> in > >>>>> practice. Slacked off a bit since, but I'd like to continue with that > >>> if > >>>>> you're agreeable. I think that branch RM role involves informally: > >>>>> - Keeping an eye on commits to branch. Periodic review of recent > >>> commits. > >>>>> Not acting as a gate on commits and not needing to be pinged or in > >> the > >>>> loop > >>>>> for every commit, except perhaps for short periods of time around > >>>> branching > >>>>> for new minors. > >>>>> - Keeping an eye on test stability. Undertaking get well projects > >> like > >>>>> bisecting and reverting offending commits to resolve test suite > >> decay. > >>>>> - Periodically kicking off new minor releases. Depends on branch and > >>> need > >>>>> for what's on deck." > >>>>> > >>>>> Interested in what folks think. > >>>>> St.Ack > >>>>> > >>>>> 1. *https://lists.apache.org/thread.html/ > >>> 247697bcfb97adeeec2d14241856ca > >>>>> 7a77a167c9efe0dbc83b0a746f@%3Cdev.hbase.apache.org%3E > >>>>> <https://lists.apache.org/thread.html/247697bcfb97adeeec2d14241856ca > >>>>> 7a77a167c9efe0dbc83b0a746f@%3Cdev.hbase.apache.org%3E>* > >>>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> > >>> -- Appy > >>> > >> > >> > >> > >> -- > >> Best regards, > >> Andrew > >> > >> Words like orphans lost among the crosstalk, meaning torn from truth's > >> decrepit hands > >> - A23, Crosstalk > >> > > > > > > > > -- > > > > -- Appy >