Rejiggering the branches

[Attila Lendvai]

>
> I'm curious -- how many of the people who want v3.3 instead of stable
> expect that they would actually interact with this branch, checking it out
> and supplying merge requests, versus just thinking it's better in some
> ideal fashion?
>
i think our mental model of version tracking is different.

imagine this scenario (that, IIUYC, you explicitly stated that you don't
want to support):

   - v4.0 is released, but it contains refactorings that require
   non-trivial efforts from users and implementations to integrate.
   - main holds quite a few shady/untested commits that will eventually
   become v4.1 (by forking off of main at a future point in time, then doing
   some testing/fixing in the release branch, and then eventually tagging its
   head as v4.1.0, then repeat and tag v4.1.1, etc).
   - v3.4 is the latest release in the v3.x line, which most
   implementations are still shipping with.
   - along comes a bugfix at this point in time, that you commit into main.

let's assume that you want to support both camps; i.e. the late adopters,
by cherry picking the fix from main into the v3.4 branch, and releasing
v3.4.n+1. and you also want to support the early adopters by cherry picking
the fix into the v4.0 branch from main. if you're lucky line-diff wise,
then this is two git cherry-pick's, and firing up the release script twice.

stale branches, that won't ever receive fixes or backports, can be deleted
(and from then on rely on the tags to retain the release history of that
now finalized branch of the version tree).

from my POV it's a pretty straightforward setup, but i'm not saying that
this scenario is something that you should or desire to support, though.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20210713/1fcd553a/attachment.html>