It works for me on linux with a build from today (b305a24), via Quarks.install("Steno", "v0.2") and via the GUI.
In Quarks.gui main window, in the quarks list, Steno version is empty though, but in the bottom window, it correctly states that v0.2 is installed (and not master rev).

@telephon - I saw that behavior circa alpha0, but I don't see it anymore. I get a repo with detached head pointing to the v0.2 change.

Hm, strange. I am on 0473427, which is very new. Maybe it isn't the version, but some other condition, e.g. whether you have a local version of the Quark as well.

I have two quark directories:

• <app support folder>/downloaded-quarks (created by sclang)
• ~/quarks (created by me and linked via Quarks.addFolder)

The second contains the development repositories that are indirectly referenced from the Quarks download mechanism.

Might be related: #1462.

Check and see who's calling Git:checkout, and with what refspec? That's the only place it can be changed afaik....

    checkout { |refspec|
        "Git:checkout(%) [stack: %, % ]".format(
            refspec,
            this.getBackTrace.caller.functionDef,
            this.getBackTrace.caller.caller.functionDef,
        ).postln;

        this.git(["checkout", refspec])
    }

Unfortunately, because different quark versions are co-located, there's nothing really preventing the installed version of a quark from being switched in unexpected ways. It might be good, in future versions, to locate the installs of different quark versions in different directories, else you have no guarantee that the Quark version you were pointing at when you wrote your code and sclang_conf will stay the same. It's a minor problem for most current cases, since almost no quarks use versions right now, but we might revisit after 3.7.

Looking at it again, I see that now (unlike before, IIRC), only my own local dev quark shows version tags, and the downloaded-quarks seems not to "see" the versions (which do exist on my github repo it points to).

Maybe tags are not yet supported in the redirect of directory.txt?

https://github.com/supercollider-quarks/quarks/blob/master/README.md

says:

"Ideally you should tag your releases with the version number and then specify it in the directory.txt:

quarkname=git://github.com/you/quarkname@tags/0.1.0"

"v0.2" is not a valid refspec.

you need to tell it that its a tag:

Quarks.install("Steno", "tags/v0.2");

This is stated in the docs:

Optional git refspec. 
By default it will install the latest version. 
Optionally you can specify 
a tag: "tags/1.0.0" 
A sha commit: "15e6ea822a18d06b286c3f10918f83b8d797d939" 
"HEAD" 
nil (default)

However it is failing silently if the tag is not found.

Should have failed:

Quarks.install("Steno", "tags/v0.3");

This is something to do with unixCmdGetStdOut. So it tries to checkout the tag, fails and then you are left on whatever you were on before (master in this case).

Bug to fix: installing with an invalid tag should throw an error. Could/should use regex to spot bogus tags before even trying to check it out.

The version string in the gui is populated with the quarkfile's declared version. Steno does not declare one. That is why it is blank.

Quarks gui could fall back to fetching the git tag if there is no version, but then it would have to do a huge number of command line operations to get the state of each repo.

When you open the bottom then it does spend the CPU cycles to check which version is really checked out.

I know this is confusing, but nearly all of these quarks have no git tags and they rely on the quarkfile. So its not easy to just switch to a new system. We could autotag all the quarks with their current version.

Other package managers have both a git tag and a version number in the package.json, setup.py etc. npm warns if there is no version number in a package.json

Ideally you should tag your releases with the version number and then specify it in the directory.txt:

Actually we can change that recommendation. By default it checks out the latest. That's fine for most everybody.

Only if you are pushing some mess into your master branch.

But people should be encouraged to do versioning. It makes development much clearer.

@crucialfelix - Would it be acceptable to append "tags/" to refspecs that don't have it? Is there another thing that a refspec can/should refer to other than a tag? Having git implementation details bubble up to the level of how we specify the version of a quark seems... not good?

sure. if it doesn't match the other possibilities: "shahash", "HEAD" then it could be assumed to be a tag and I can insert tags/ automatically.

the problem with unixCmdGetStdOut is that it does not get the exit code. we could create and throw an Error if the exit code != 0 and then return the output in the Error message. that would break somebody's code.

unixCmd has a callback but also does not get a exit code. but we could add that as a new argument passed to the callback. that would not break anybody's code.

but then we need promises or call these things in routines and block.

all of quarks is currently sync and blocks. because adding Promise was out of scope for the project.

many people who were once wild about Promises are now leaning towards await

to clarify: the PR fixes both issue mentioned here. it would correctly checkout "v0.2" as "tags/v0.2" and it would post an error if you specify a tag that does not exist.