Rejiggering the branches

[Raymond Toy]

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

> On 13 Jul 2021, at 10:20, Eric Timmons wrote:
>
> Attila Lendvai <attila.lendvai at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20210714/1b45df93/attachment.html>