Hi, I wanted to ask about what you think is the best way of working with nuttx/apps repo for a downstream user considering the new release branching strategy.
Previously I was used to having the master branch contain release tags so I would generally work on top of these tags creating local commits on my project specific branch, inside a fork of nuttx/apps, if needed. Then, whenever a new version of NuttX was released, I could rebase my branch to the new release tag. Moreover, this local branch will usually contain a series of commits which I intend to upstream (fixes/improvements). To do so, I would create a branch stemming from master (or, at least, the most recent release tag) and then cherry-pick these commits there. To contribute this in the form of PRs I would do this creating one branch for each PR. At the end of each PR acceptance I can then rebase my main working branch to the new tip and the rebase would recognize these upstreamed commits and would not generate any conflicts. In the end, my branch would only contain non-upstreamed commits. Now, I'm facing a problem whereas I would like to work on top of stable releases but since these are tips of branches that are never merged back to master, rebasing as previously described introduces many conflicts between commits which are backported from master to these branches. To me it is strange that these release branches are never merged and no release tag seems to exist. Most projects I worked with usually tag release commits and they are always part of the main history. I'm wondering if maybe there's something I could change in my workflow or maybe the release branching/tagging strategy could be adapted to ease downstream work. For example, if there would be something as a feature-freeze window some time before a release, disruptive PRs (ie: non bug fix PRs) against master could be held until master is stabilized and released with a tag. In this scenario I think release branches are not needed, the resulting history is linear and there are no unmerged tips. Best, Matias
