Functionally, yes. But git has troubles recognizing that the cherry-picked commits are the same on master and generates conflicts. The merge would solve this in theory, since the release branch tip would end up matching a commit on master.
On Mon, Jun 15, 2020, at 16:31, Abdelatif Guettouche wrote: > 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 > > >> > > > >
