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. > > > > 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. > > The last release was probably not a good indicator of how far the > release branch will deviate (there were a lot of backported fixes). > But part of the reason it is not feasible to just merge back in is two > fold: > 1. We want to have these branches for bug fix releases. The last > release did not have one, but there likely should have been one for at > least one bug that was found related to loading binaries > 2. With the Apache release process it takes a long time for releases > to get out the door. Once a RC is created it is likely 1-2 weeks > before it is actually released. There are two three day voting periods > and for example the last release one of those voting periods took a > week. We also had to do 2 release candidates each time we do that the > clock gets reset. In the mean time a lot of changes are happening in > master, even today just after the release branch was created a lot of > large changes went into master. 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. Going back to the alternative workflow of the feature-freeze window, you could also work on a separate "staging branch" instead of on master until a release is deemed final, where all disruptive PRs are collected. Then, once the latest release is deemed final, you can safely merge staging to master. In any case, what I suggested (regardless of the chosen workflow) is to not leave unmerged branches. > > What I suspect would actually work well is to change your rebase > strategy to instead of rebasing your entire branch (off of release > branch), but instead to rebase only your commits onto master or the > next release branch: > git rebase --onto dest first_commit last_commit > > With this you would exclude all of the backport commits which are > likely the source of the rebase troubles. > > I hope that helps. > > --Brennan > I guess that would work. It is a bit more painful and manual but I guess I will try that next time if release branches stay unmerged. Thanks for the suggestion. Best, Matias
