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 >
