> On Jan 13, 2020, at 11:35 AM, Nathan Hartman <hartman.nat...@gmail.com> wrote:
>
> On Mon, Jan 13, 2020 at 2:12 PM David S. Alessio <david.s.ales...@gmail.com>
> wrote:
>
>>
>>
>>> On Jan 13, 2020, at 5:14 AM, Gregory Nutt <spudan...@gmail.com> wrote:
>>>
>>>
>>>> I think once the workflow is complete we should froze the master and
>>>> keep accepting patch into dev branch. This is my point of view, I
>>>> don't know if we will implement it.
>>>
>>> I think we should create a release branch and freeze nothing. Versioning
>> will need to extend to 3 numbers, so the next would be 8.4.0. Every
>> release will have to live on a branch with multiple release candidates up
>> to the released version, perhaps tagged like nuttx-8.4.0-rc1. If bugs are
>> found after the release, the code could be re-released as 8.4.1 and the
>> bugfix merged back to main.
>>>
>>
>> I’d like to suggest the release branches be named:
>> releases/8.4.0-rc1
>> releases/8.4.0
>> releases/8.4.1
>>
>> etc.
>>
>> As 8.4.0-r1 evolves and converges on a stable release, it can be merged
>> into 8.4.0.
>>
>> Regards,
>> -david
>>
>
> As the branches should be long lived, I suggest fewer branches by calling
> the branch "8.4.x" and then using tags (also long lived) to tag 8.4.0-rc1,
> 8.4.0, 8.4.1-rc1, etc.
That can work.
> Any bugs get fixed on master and backported to the
> branch. Changes don't get committed directly to the branch.
I see two possible scenarios:
1. a release is cut in stone and doesn’t get patched, the patched release
becomes 8.4.1, for example
or
2. if a release branch can be patched, then we have to allow for a hotfix patch
to be applied to that release branch. There’s a scenario where the code to be
patched no longer exists on Master, it has been replaced with a different block
of code...
>
> Nathan
>
>
>>
