On Tue, Jul 13, 2021 at 9:34 AM Attila Lendvai <attila.lend...@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
