On 05/23/2017 04:05 AM, Karel Zak wrote: > 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. Argh, my brain was broken. I wrongheadedly believed that this project was using linear development. > > And yes, NEWS file in the master does not contain info about > maintenance release (e.g. v2.29.1). Maybe it's mistake. No, I was the 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. It's all clear now that you've pulled my head out of ... its 'master' branch walled garden. The stable maintenance tags are not reachable from, pulled by, or have anything else to do with the 'master' branch. They belong only to their respective forked stable branches being developed independently. Hinting about them in master would probably be misleading. I think I will submit a patch to add something to Documentation about this so that someone else might not ask the same dumb questions. With your permission, I might include your well written workflow description. Sorry for wasting your time Karel (and anyone else reading this). Thank you for setting me straight. > > Karel > -- 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
