Re: versioning

[Ruediger Meier <sweet_f_a@gmx.de>]

On Tuesday 23 May 2017, J William Piggott wrote:
> 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.

FYI there is also "man 7 gitworkflows", worth to read IMO.

Beside the trivial fact that they use "maint" instead of "stable" they 
always provide one non-versioned "stable" branch which contains *all* 
tags, more easy to be followed by users. To be able to do that they 
*commit* bugfixes only to "stable" and *merge* them into master 
(instead of cherry-picking from master).

cu,
Rudi

> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html