consider switching to an apt-style repository architecture

[bacongobbler]

Having a git-backed repository structure makes the forking and maintenance model incredibly simple for the back-end, however it comes with the trade-off of only having the ability to install the latest version of a package.

As a user, I should be able to install a package at a version that was previously made available from a package repository:

$ gofish install helm --version 2.8.2

[tyrken]

Definitely agree that installing other versions is necessary. Why not allow a given Food to support multiple versions simultaneously (perhaps with a specified default, or default-to-latest)?

E.g. Shift the "version" data into the package list, and allow multiple packages to be defined. Allow shorter/smarter lua definitions by having a "valid_versions" key in the package to a list of versions-to-tables for any changing fields, i.e. the sha256 & possibly the url. I say possibly as with some templating such as "https://someplace.com/releases/my-util-${version}.zip" maybe you usually wouldn't need to override the url.

[bacongobbler]

That's not a bad idea. I'll play around with that.

[bacongobbler]

I've seen winget use @tyrken's pattern. The more I think about it, the better that style starts to look. I'll have a look at implementing this for 0.14.0 (we have plenty to release in 0.13.0, so I'm going to ship a new release today).

This also reinforces my decision to choose Lua as the language for fish food. Lua's starting to pay in dividends now. Each fish food can include a "common" script that can share functions across versions, like the download URL format. Can't say the same with YAML/JSON!