<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>Would the "stable" branch be any different from the "release" branch?<br>
If it's actually a not-so-stable development branch for 3.3 while a<br>
separate branch contains development for 3.4, then maybe indeed<br>
calling branches v3.3 and v3.4 make more sense.<br><br></blockquote><div><br></div><div>+1</div><div><br></div><div>what i would do:</div><div><ul><li>one branch that holds the bleeding edge. i'd call it main, just to go with the flow.</li><li>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.</li><li>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...</li></ul><div><div>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.</div><div><br></div></div></div><div>- attila</div><div><br></div></div></div>