On Tue, Jul 13, 2021 at 1:35 PM Robert Goldman <rpgoldman@sift.info> wrote:

On 13 Jul 2021, at 10:20, Eric Timmons wrote:

Attila Lendvai <attila.lendvai@gmail.com> writes:

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...

I like this!

IMO a big win of having the major and minor number in the branch name is
that it's a better experience for users. If it's a single `maintenance`
branch then a git pull may wind up changing their version completely. If
they have any local changes as well, things might get a bit hairy when
`maintenance` changes minor versions as that wouldn't be a fast-forward
update.

I guess I'm surprised you say this. I don't ever want us to have more than a single live maintenance branch. I absolutely never want to support more than a single main version and a single stable version.

So, to me, it's a feature that if you git pull maintenance and you find out that what you are maintaining has changed. And to me it seems like a bad user experience if I can end up wasting my time interacting with a branch that is obsolete and of no further interest. I'd rather know that things have changed -- and I would expect to do git pull --ff-only on stable.

I am surprised that so many people want to have a branch like v3.3. This adds a memory burden that stable doesn't have, in the same way that Raymond pointed out that having dev adds a memory burden beyond using the standard main or master. Honestly, I find it hard to remember whether 3.3 or 3.4 is the current released version!

I think it's easy to tell since the numbers are increasing, so if there's v3.3 and v3.4, then v3.4 is the current released version. If you're working on v3.4, then I would expect things to be on main until you're ready and then a v3.4 branch is made. This keeps getting updated until it's release at which point a tag could be added to indicate the release.

But all of this requires work. And since I'm not the one doing the work, I defer to you for the final decision.

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?

If there are tags (or branches) to indicate when the release is done, then a stable branch is ok with me. I just want a way to get to a release somehow. (Not that I've had to debug an issue in asdf. But if I did, I want to be able to extract various releases for testing.)

Ray