Sure, that sounds good. We have a consensus to do more frequent minor releasing so there is no problem bumping minors whenever needed on branch-1. Let's play it by ear.
On Fri, Dec 21, 2018 at 12:09 AM Francis Christopher Liu < [email protected]> wrote: > > If you have local changes you’d like to upstream please open JIRAs or > update the fix version on existing to include 1.5.0 so we can gather them > into a list and consider them. Although, I’d like to release 1.5.0 in > January 2019 so maybe we need a new fix version of 1.6.0 to denote > significant changes to hit later in the year? (Like split meta?) > > That'd be great if we can get it in a branch-1 release. Tho it's a stretch > to make it by January 2019 so prolly 1.6 then. To start I'll work on > putting up the split meta patch and we'll put up other smaller patches > while we get this one in. > > > > On Wed, Dec 19, 2018 at 9:32 AM Andrew Purtell <[email protected]> > wrote: > > > Upstreaming local changes into a new (minor?) Apache release that we can > > circle around and upgrade to is our strategy too. One of my goals with > > branch-1 and upcoming releasing of 1.5.0 is that 1.5 is a functional > > superset of everything we depend on in production as well as all the > other > > community improvements. Perhaps 1.5 can serve in the same way for you? If > > you have local changes you’d like to upstream please open JIRAs or update > > the fix version on existing to include 1.5.0 so we can gather them into a > > list and consider them. Although, I’d like to release 1.5.0 in January > 2019 > > so maybe we need a new fix version of 1.6.0 to denote significant changes > > to hit later in the year? (Like split meta?) That’s fine too. But let’s > > organize your needs in a way we can track them. > > > > > > On Dec 19, 2018, at 12:52 AM, Francis Christopher Liu < > > [email protected]> wrote: > > > > >> Granted, 1.3 was never declared the "stable" release line so folks > > should > > > have expected it could die off whenever, but it really sucks to not see > > > releases when you've decided to use a release line. All downstreamer > > users > > > shouldn't have to maintain a fork. > > > > > > Agreed, this is my fault and I apologize for that. > > > > > >> I've found in maintaining the 1.2 release line that the RM has to > > > proactively review all the commits at least up to the major release > line > > in > > > order to make sure things get included. As mentioned in a few > different > > > DISCUSS threads, we have too many branches active and committers have > > > limited bandwidth so stuff gets missed. just doing it as a part of the > > > release takes quite some time if one hasn't been keeping an eye out. > > > > > > Agreed, I noticed this as well when cutting 1.3.2. There were a lot of > > > backporting jiras in the release. I also had the intent to monitor > > branch-1 > > > for missed backports thanks for reminding me. If doing releases at a > > > monthly cadence then it won't be too bad during the time of release? > > > > > >> FWIW, I agree that effort towards getting your deployment onto a > future > > > branch-1 release would be better. It'd be nice if that could include > > > discussing what it would take for periodic updates to future branch-1 > > minor > > > releases to become your plan instead of e.g. sticking to branch-1.4.z > > > > > > Yes my proposal encapsulates that. Essentially if we push most of our > > > patches (especially the big ones) upstream then it won't be as big an > > > effort to move between branches that have them. (Also addressing the > > > question why it's difficult to move from 1.3 to 1.4). > > > > > >> On Mon, Dec 17, 2018 at 5:41 PM Sean Busbey <[email protected]> > wrote: > > >> > > >> If I really stop to reflect on it, I'm fine with whatever for the > > branch. I > > >> just want to make sure we're proactively setting expectations for > > >> downstream users. > > >> > > >> Granted, 1.3 was never declared the "stable" release line so folks > > should > > >> have expected it could die off whenever, but it really sucks to not > see > > >> releases when you've decided to use a release line. All downstreamer > > users > > >> shouldn't have to maintain a fork. > > >> > > >> I've found in maintaining the 1.2 release line that the RM has to > > >> proactively review all the commits at least up to the major release > > line in > > >> order to make sure things get included. As mentioned in a few > different > > >> DISCUSS threads, we have too many branches active and committers have > > >> limited bandwidth so stuff gets missed. just doing it as a part of the > > >> release takes quite some time if one hasn't been keeping an eye out. > > >> > > >> FWIW, I agree that effort towards getting your deployment onto a > future > > >> branch-1 release would be better. It'd be nice if that could include > > >> discussing what it would take for periodic updates to future branch-1 > > minor > > >> releases to become your plan instead of e.g. sticking to branch-1.4.z > > >> > > >> On Mon, Dec 17, 2018, 18:38 Francis Christopher Liu < > > [email protected] > > >> wrote: > > >> > > >>>> How about we have a probationary period where the RM takes care of > > >>> pulling in changes for branch-1.3 releases? After say a quarter of > > >>> hitting a monthly cadence we go back to committers proactively > > >>> including the branch. > > >>> > > >>> How about I just release monthly during the probationary period? > > >> Monitoring > > >>> and backporting all patches sounds like effort that would be better > > >>> allocated to open sourcing our internal patches? Or if you want some > > >>> measure of me/us upstreaming patches (works towards moving to a newer > > >>> branch). That seems much more beneficial for all? > > >>> > > >>> > > >>> > > >>>> On Mon, Dec 17, 2018 at 3:09 PM Sean Busbey <[email protected]> > > wrote: > > >>>> > > >>>> I've worked to get back to monthly because I don't think quarterly > is > > >>>> often enough to be useful. (but take this with a grain of salt > since I > > >>>> am not a user of the branch in question) > > >>>> > > >>>> - 1.2.9: 2018-11-27 > > >>>> - 1.2.8: 2018-10-20 > > >>>> - 1.2.7: 2018-09-16 > > >>>> > > >>>> I'll be starting 1.2.10 soon. > > >>>> > > >>>> I'm still happy to have releases from an EOL branch. I just expect > > >>>> that the RM will handle the backporting process for that branch so > > >>>> committers don't have to worry about it when accepting > contributions. > > >>>> > > >>>> How about we have a probationary period where the RM takes care of > > >>>> pulling in changes for branch-1.3 releases? After say a quarter of > > >>>> hitting a monthly cadence we go back to committers proactively > > >>>> including the branch. If we don't hit the releases then we declare > the > > >>>> branch EOL. That designation which still would allow for releases, > but > > >>>> would change cadence expectations, update status on the downloads > > >>>> listing, docs, and avoid committers having to think about the > branch. > > >>>> On Mon, Dec 17, 2018 at 1:32 PM Andrew Purtell <[email protected] > > > > >>>> wrote: > > >>>>> > > >>>>> I have been releasing 1.4 semi-monthly (usually, monthly) and Sean > > >> has > > >>>> been > > >>>>> releasing 1.2 every quarter. So maybe quarterly releases would be > > >> good? > > >>>>> What do others think? What is the minimum release schedule to make > it > > >>>> worth > > >>>>> your while for commits/backports to a branch? At least once every > > >> half > > >>>>> year? More often? > > >>>>> > > >>>>> On Mon, Dec 17, 2018 at 11:23 AM Francis Christopher Liu < > > >>>>> [email protected]> wrote: > > >>>>> > > >>>>>>> Given there was no release activity on 1.3 all year may I ask how > > >>>> you are > > >>>>>> using 1.3? Are you consuming upstream changes by cherry pick into > > >> an > > >>>>>> internal branch? > > >>>>>> It depends on the urgency of an internal release we either pull in > > >>> all > > >>>>>> changes up to a release, tip or cherry-pick. For the more recent > > >>>> releases > > >>>>>> we've been cherry picking. Tho we intend to pull in all changes > > >>> again. > > >>>> BTW > > >>>>>> I did release 1.3.2 in March. > > >>>>>> > > >>>>>>> It’s great that you’ve stepped forward to offer ongoing RM > > >> activity. > > >>>> We > > >>>>>> will need this commitment and a new pattern of more frequent > > >>> releasing > > >>>> to > > >>>>>> justify keeping the code line alive, I think. > > >>>>>> Let me know what would be an acceptable release cadence and I'll > > >>> carve > > >>>> out > > >>>>>> time. > > >>>>>> > > >>>>>>> Did you see that I stepped forward to make a release? There is a > > >>> VOTE > > >>>>>> thread now for 1.3.3RC0. Perhaps we can start there? Would you > use > > >>> it? > > >>>>>> Would you +1? Or are there changes in there that are of concern? > > >>> Please > > >>>>>> consider commenting on the VOTE. > > >>>>>> Yes we will use it, my intention is to be as current to branch-1.3 > > >> as > > >>>>>> possible. Yes, I intend to vote on the release. I am currently > > >>> running > > >>>> the > > >>>>>> unit test and going through the release. Apologies for you having > > >> to > > >>>> cut > > >>>>>> the release. > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Francis > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> On Mon, Dec 17, 2018 at 8:48 AM Andrew Purtell < > > >>>> [email protected]> > > >>>>>> wrote: > > >>>>>> > > >>>>>>> It’s been a year since the last release. For what it’s worth I > > >> see > > >>> no > > >>>>>> harm > > >>>>>>> in continuing to release 1.3, but you have to consider how > > >>>> burdensome it > > >>>>>> is > > >>>>>>> to have an open code line that bug fixes need to be committed > > >> into. > > >>>> Given > > >>>>>>> there was no release activity on 1.3 all year may I ask how you > > >> are > > >>>> using > > >>>>>>> 1.3? Are you consuming upstream changes by cherry pick into an > > >>>> internal > > >>>>>>> branch? Or are you not consuming any upstream changes at all? If > > >>> the > > >>>>>>> latter, then what’s the point? If the former, it still isn’t > > >> great, > > >>>>>> because > > >>>>>>> while changes may be getting out into production somewhere it’s > > >>> only > > >>>> you > > >>>>>>> who is benefitting. We need releases from branch-1.3 a lot more > > >>>>>> frequently > > >>>>>>> or it’s a bad deal for the community. Committers have to deal > > >> with > > >>>>>>> effectively a dead branch. Users get no releases. Given the > > >>> consensus > > >>>>>>> expressed on this thread we don’t want this deal. It’s great that > > >>>> you’ve > > >>>>>>> stepped forward to offer ongoing RM activity. We will need this > > >>>>>> commitment > > >>>>>>> and a new pattern of more frequent releasing to justify keeping > > >> the > > >>>> code > > >>>>>>> line alive, I think. > > >>>>>>> > > >>>>>>> Did you see that I stepped forward to make a release? There is a > > >>> VOTE > > >>>>>>> thread now for 1.3.3RC0. Perhaps we can start there? Would you > > >> use > > >>>> it? > > >>>>>>> Would you +1? Or are there changes in there that are of concern? > > >>>> Please > > >>>>>>> consider commenting on the VOTE. > > >>>>>>> > > >>>>>>> > > >>>>>>>> On Dec 17, 2018, at 8:31 AM, Francis Christopher Liu < > > >>>>>>> [email protected]> wrote: > > >>>>>>>> > > >>>>>>>> Hi, > > >>>>>>>> > > >>>>>>>> Apologies a bit late to this discussion. I would still like to > > >>>> continue > > >>>>>>>> making 1.3 releases. If the concern is having a better cadence > > >> of > > >>>>>>> releases > > >>>>>>>> let me know how often the community would like (quarterly, > > >> every > > >>>> other > > >>>>>>>> month, etc) and I'll make sure to carve out time with my > > >>> employer. > > >>>> We > > >>>>>>> will > > >>>>>>>> be on 1.3 for a while. I believe it would be beneficial for the > > >>>>>> community > > >>>>>>>> and my employer for us to be on an active release line, hence > > >> my > > >>>>>>> interest. > > >>>>>>>> > > >>>>>>>> Let me know what you guys think? > > >>>>>>>> > > >>>>>>>> Thanks, > > >>>>>>>> Francis > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> On Mon, Dec 10, 2018 at 6:04 PM Andrew Purtell < > > >>>> [email protected]> > > >>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>> Thank you all for your comments. It looks like we have > > >> consensus > > >>>> to > > >>>>>> EOL > > >>>>>>> 1.3 > > >>>>>>>>> and RM one final release. I will start working on that > > >> release, > > >>>> 1.3.3, > > >>>>>>> now. > > >>>>>>>>> > > >>>>>>>>>> On Mon, Dec 10, 2018 at 8:50 AM Josh Elser < > > >> [email protected]> > > >>>>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>> +1 > > >>>>>>>>>> > > >>>>>>>>>>> On 12/7/18 2:24 PM, Andrew Purtell wrote: > > >>>>>>>>>>> We haven't had a release from branch-1.3 for a long time and > > >>> do > > >>>> not > > >>>>>>>>>> appear > > >>>>>>>>>>> to have an active RM for it. Unless a RM for 1.3 steps > > >> forward > > >>>> and > > >>>>>>>>>> promises > > >>>>>>>>>>> to make a release in the very near future, I propose we make > > >>> one > > >>>>>> more > > >>>>>>>>>>> release of 1.3, from the head of branch-1.3, and then retire > > >>> the > > >>>>>>>>> branch. > > >>>>>>>>>> If > > >>>>>>>>>>> this is acceptable I can RM the final 1.3 release. > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> -- > > >>>>>>>>> Best regards, > > >>>>>>>>> Andrew > > >>>>>>>>> > > >>>>>>>>> Words like orphans lost among the crosstalk, meaning torn from > > >>>> truth's > > >>>>>>>>> decrepit hands > > >>>>>>>>> - A23, Crosstalk > > >>>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>>> > > >>>>> -- > > >>>>> Best regards, > > >>>>> Andrew > > >>>>> > > >>>>> Words like orphans lost among the crosstalk, meaning torn from > > >> truth's > > >>>>> decrepit hands > > >>>>> - A23, Crosstalk > > >>>> > > >>> > > >> > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
