Rejiggering the branches

[Faré]

On Tue, Jul 13, 2021 at 9:34 AM Attila Lendvai <attila.lendvai at gmail.com> wrote:
>>
>>
>> Would the "stable" branch be any different from the "release" branch?
>> If it's actually a not-so-stable development branch for 3.3 while a
>> separate branch contains development for 3.4, then maybe indeed
>> calling branches v3.3 and v3.4 make more sense.
>>
>
> +1
>
> what i would do:
>
> one branch that holds the bleeding edge. i'd call it main, just to go with the flow.
> branches for ASDF versions (down to the desired resolution, probably major.minor), so that you can easily cherry pick or backport fixes into them. a new version-branch is forked off of main whenever a release happens.
> optionally a stable *tag* as an indirection to the latest release. it communicates which specific git revision is it that the maintainer considers the stable state at any moment in time. it comes handy e.g. in CI scripts that want to check out the latest ASDF release, etc...
>
> note though that this last point requires force-pushing the stable tag, which i have done before, but i'm not completely sure it results in a slick workflow. the main question is whether or not a git fetch/pull silently and automatically updates the tag in the local repo.
>
Nah, a tag is supposed to never change. The mechanism for a "tag that
changes" is called... a branch. And that's precisely why we have a
release branch. And yes, if we have version-based branches v1, v2,
v3.0, v3.1, v3.2, v3.3, v3.4... then it makes sense to force-push to
the release branch when the release "jumps" from v3.3 to v3.4... or to
"merge" the latest release into master or main before to make a new
release off of it so there is no need for force.

—♯ƒ • François-René Rideau • Co-Founder and CEO, MuKn.io
Love thy neighbor as thyself, but choose your neighborhood.
                — Louise Beal