> The patch, however, could be an option. Some files will need to adapt > to that though, not only the version.sh script.
I submitted a PR for that. Please take a look. (https://github.com/apache/incubator-nuttx/pull/827) I backported some trivial changes and bugfixes from master to the release branch. I guess once the release notes and this PR (if it gets merged) are backported we can go ahead and create the tarballs then call for a vote. Brennan, I understand that you have a script to upload the tarballs to where they should be. Can you do that once we get everything in place? They need to be signed as well. On Thu, Apr 16, 2020 at 2:10 AM Abdelatif Guettouche <abdelatif.guettou...@gmail.com> wrote: > > I don't think we need to expose the RC, it's not the one that's going > to be released. > The patch, however, could be an option. Some files will need to adapt > to that though, not only the version.sh script. > > > On Wed, Apr 15, 2020 at 5:33 PM Brennan Ashton > <bash...@brennanashton.com> wrote: > > > > On Wed, Apr 15, 2020, 9:29 AM Abdelatif Guettouche < > > abdelatif.guettou...@gmail.com> wrote: > > > > > > We should probably figure out how this patch would be represented in > > > > code > > > > and if we want to have 9.0.0-RC1 or whatever supported. > > > What do you mean in code? > > > A release will go through possibly multiple release candidates all > > > tagged as 9.0.0-rcX, the final tag will be the same as the last > > > accepted RC without the -rc suffix. > > > Patches will have to go through the same process. With the voting in > > > the incubator general list, etc. > > > > > > > There is a version file that is generated but it only exposes major, minor, > > and build hash as defines for code to use. Do we need to extend the code to > > support a patch version? And should the RC be exposed to the code as well > > somehow (probably less important). > > > > >
