<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 13 Jul 2021, at 10:20, Eric Timmons wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Attila Lendvai <attila.lendvai@gmail.com> writes:</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">what i would do:<br>
<br>
- one branch that holds the bleeding edge. i'd call it main, just to go<br>
with the flow.<br>
- branches for ASDF versions (down to the desired resolution, probably<br>
major.minor), so that you can easily cherry pick or backport fixes into<br>
them. a new version-branch is forked off of main whenever a release happens.<br>
- optionally a stable *tag* as an indirection to the latest release. it<br>
communicates which specific git revision is it that the maintainer<br>
considers the stable state at any moment in time. it comes handy e.g. in CI<br>
scripts that want to check out the latest ASDF release, etc...<br>
</p>
</blockquote><p dir="auto">I like this!<br>
<br>
IMO a big win of having the major and minor number in the branch name is<br>
that it's a better experience for users. If it's a single `maintenance`<br>
branch then a git pull may wind up changing their version completely. If<br>
they have any local changes as well, things might get a bit hairy when<br>
`maintenance` changes minor versions as that wouldn't be a fast-forward<br>
update.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">I guess I'm surprised you say this. I don't <em>ever</em> want us to have more than a single live maintenance branch. I absolutely <em>never</em> want to support more than a single <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">main</code> version and a single <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">stable</code> version.</p>
<p dir="auto">So, to me, it's a <em>feature</em> that if you git pull maintenance and you find out that what you are maintaining has changed. And to me it seems like a <em>bad</em> 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 <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">git pull --ff-only</code> on <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">stable</code>.</p>
<p dir="auto">I am surprised that so many people want to have a branch like <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">v3.3</code>. This adds a memory burden that <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">stable</code> doesn't have, in the same way that Raymond pointed out that having <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">dev</code> adds a memory burden beyond using the standard <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">main</code> or <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">master</code>. Honestly, I find it hard to remember whether 3.3 or 3.4 is the current released version!</p>
<p dir="auto">I'm curious -- how many of the people who want <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">v3.3</code> instead of <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">stable</code> 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?</p>
</div>
</div>
</body>
</html>