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.
> > 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. --Brennan
