chrysn

That usually gets updated manually, so indeed this PR will need to wait until we next update things after a release is out with the changed locations. In the meantime,...

I think this should update the tag too. (AIU, VERSION_TAG is what gets set on the riotdocker image -- ie. it needs to be there before the release already.) Do...

> I think this should update the tag too. (AIU, VERSION_TAG is what gets set on the riotdocker image -- ie. it needs to be there before the release already.)...

No, the tag is still useful: Anyone who uses, say, RIOT 2023.07 can still get the 2023.07 docker container. While we usually take some time to do the bumping update...

I think the right resolution here is not to not expand the macro. Even if the *outcome* of the expansion is the same (be it, as in this case, because...

Thanks for the rebase, I'll combine that in with my pending changes. I've been testing this for the last months in a limited scope – and just found out that...

> I wonder if it wouldn't be nice to include a `dist/tools` script similar to `dist/tools/uf2` or `dist/tools/picotool`, so that the user does not have to deal with installing the...

Mainly that I'd hope for a nrfdfu release soonish so we don't tell people to `cargo install --git https://github.com/so/mething` but just `cargo install something`. (But I could probably just declare...

> You know what would solve that? A Makefile in dist/tools that specifies the hash for Cargo 👀 🤣 No it wouldn't: Unless we go through our own local installations...

> That is not true for all tools. The aforementioned picotool for example is always fetched from remote. It is true for the tools I've worked with, but you're right,...