Feature Request: Version-pin core functions (build.func, api.func, etc.) via GitHub Releases for improved security auditing

[funtri-vt]

First off, thank you to the team for maintaining this project - it is such a great resource.

I have an idea that might improve the security of pulling core scripts (like api.func or build.func): allowing the app scripts to version lock to a specific release of those core files. This way, when someone is auditing an install script, they know it's sourcing a proven, trustworthy release of the core functions. It leaves reviewers with a lot less code to manually verify each time.
To implement this without changing the repo structure too much, maybe the core files could use GitHub releases, and each tool's script just points its sourcing URLs to that specific release tag instead of pulling from main.

This is just an idea I had while looking through the repo, so absolutely no pressure to implement it if the team feels the maintenance effort isn't worth the benefit. Thanks again for all the hard work!

Comment update: deleted unnecessary revisions that had previously hard to read wording or missing sections

[MickLesk]

Doesn’t really make sense for our setup.

We’re a very small team (3–4 people), and maintenance is already a significant effort. (i invest more then my half freetime every day) Introducing version pinning or release-based revisions would add a lot of overhead, fragment the codebase, and make it harder to roll out fixes consistently.

We also already struggle with limited input in many issue reports. Quite often we have to chase down basic information, and it’s not always clear whether something is actually a bug or just a local/environment issue. With pinned versions, this gets significantly worse — we wouldn’t be able to reliably reproduce issues or tell if something has already been fixed upstream.

Right now we rely on a single source of truth, so fixes apply everywhere immediately and we can debug against a known state. Version pinning would introduce multiple active revisions in the wild, making debugging, support, and security patching much more complex.

Appreciate the idea, but in practice it would increase complexity and support overhead without providing enough real benefit for how this project operates.

[funtri-vt]

Thanks for the detailed reply! That makes total sense - I hadn't quite considered the support nightmare of trying to debug multiple active versions in the wild with a small team. I really appreciate you taking the time to explain the reasoning. We can go ahead and consider this discussion closed. Thanks again for all the hard work!