On Tue, May 23, 2017 at 09:57:33AM +0200, Karel Zak wrote:
> On Mon, May 22, 2017 at 05:37:28PM -0400, J William Piggott wrote:
> > My thoughts are that bugfix releases should be committed to 'master' the
> > same as the stable/rc releases are. Then the tag created from that commit.
>
> How do you want to commit bugfix release (e.g. v2.29.2) to the
> 'master' if the master and 'stable/' branches contain a different
> code?
>
> The current workflow:
>
> 1) development (branch: <master>)
>
> 2) master release (tags: v2.29-rc1, v2.29-rc2, v2.29, branch: <master>)
>
> 3) development (work on v2.30, branch: <master>)
>
> 4) fork -- create a new branch <stable/v2.29> based on tag v2.29
>
> 4a) new patches or cherry-pick patches from <master> (branch: <stable/v2.29>)
>
> 4b) stable release (tag: v2.29.1, branch: <stable/v2.29>)
>
> 4c) another patches, another release (tag: v2.29.2, branch: <stable/v2.29>)
>
> 5) master release v2.30 (branch: <master>)
> ...
>
>
> where 3) and 4) happen in the same time.
And yes, NEWS file in the master does not contain info about
maintenance release (e.g. v2.29.1). Maybe it's mistake.
This information is in the ReleaseNotes where are links to the
previous maintenance releases.
We can add a hint about maintenance releases to the master branch NEWS
file, but stable maintenance tags (v2.29.1) has to be in the stable/
branches. It's released code what has to be tagged and signed.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
