> Yes, it's better to accumulative all patch for a specific release candidate > in an issue/request in the future release, then we can track each release > more easier.
Commit wise, we would have the same history, or are you suggesting to squash all the backported commits? On Sat, May 23, 2020 at 7:40 AM Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > > > > > -----Original Message----- > > From: Nathan Hartman <hartman.nat...@gmail.com> > > Sent: Saturday, May 23, 2020 5:11 AM > > To: dev@nuttx.apache.org > > Subject: Re: Release Notes for the NEXT version of NuttX > > > > On Fri, May 22, 2020 at 4:54 PM Brennan Ashton <bash...@brennanashton.com> > > wrote: > > > Nevermind I see what you were asking for. There is no great way to do > > > this with git directly, usually you track this by using labels (or > > > similar) on issues or PRs to aggregate it. At least that is that is > > > how I have always run releases for work. > > > > Ugh, I don't think we've done that. At least, we haven't consistently. > > > > So, I'm guessing we'll have to take the log since that branch point, but > > then manually exclude the commits that were cherry-picked to > > 9.0? > > Sounds like a lot of effort. :-( > > > > Yes, it's better to accumulative all patch for a specific release candidate > in an issue/request in the future release, then we can track each release > more easier. > > > Nathan >
