The release branch doesn't contain anything that's not already present in master. The log between the two branches (a release and master) are just the cherry picked commits. So there is nothing really to merge back.
On Mon, Jun 15, 2020 at 7:13 PM Matias N. <mat...@imap.cc> wrote: > > As a reference, this merging back is used in GitFlow, so I guess it should > work: > https://datasift.github.io/gitflow/IntroducingGitFlow.html > (see 4th figure) > > On Mon, Jun 15, 2020, at 15:09, Matias N. wrote: > > On Mon, Jun 15, 2020, at 15:04, Brennan Ashton wrote: > >> On Mon, Jun 15, 2020 at 10:47 AM Matias N. <mat...@imap.cc> wrote: > >> > > >> > There are release tags created: > >> > > https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1 > >> > > >> > I understood that as a release candidate, not a final release. Anyway, > >> > this just points to the tip of release/9.0 so it does not change my > >> > situation. > >> > > >> Sorry, this is my oversight, I probably should have tagged that commit > >> at nuttx-9.0.0 as well once it was approved by IPMC for release. I > >> will create a signed tag this evening for both os and app, but yes the > >> latest RC is the actual release. A bug fix release would be seen as a > >> tag on the same branch with the patch number increased. The reason to > >> rely on the tag and not the tip, is that any bug fix commit for a > >> patch release would also go here and have that same multi-week window > >> before it is released. > > > > No problem! > > > >> > > >> > The ability to correct bugs after a release without having to also > >> > include features that were added in between is understandable. But I > >> > don't really understand why that does not allow to merge the release > >> > branch back to master once it is considered final. Unless I'm mistaken > >> > this should not create conflicts and would only "close the loop" and let > >> > git later now how to deal with rebases between final release points > >> > easily. > >> > > >> > >> We can certainly give it a go on a temporary branch for this next > >> release and see if that makes for a better workflow and if so apply > >> the merge to master. We have been trying to only do fast-forward > >> merges, but this might be worthy of an exception to that. > > > > Cool. It is good to test on a temporary branch and see if the idea works. > > It would make upgrading between nuttx releases an easier process. > > > >> --Brennan > >> > >
