Make `-version` flag work for unreleased versions

[CatsDeservePets]

• Follow-up to https://github.com/gokcehan/lf/pull/1517.

The mentioned PR did update the -version flag to show current git commit and Go version for unofficial versions (instead of an empty output).

In there, @ilyagr mentioned:

I was also thinking about an alternative plan: --version could just print the commit id, and there could be a separate --verbose-version option to print everything (including the official version, if present). However, I decided we don't really have to think about that too hard now. We can merge this and then see whether there's a demand for something more complicated.

I'd argue that lf should output the ~~last official version it is based on~~ unreleased version of the current milestone. Otherwise, version tests like mentiont in Tips are not possible.

As someone who is involved in lfs development and constantly runs different versions to test out various things, I constantly get error messages about unknown options. The only solutions I currently have are either passing different configuration files for different executables or checking the path of the executable. Having -version still output a version on top would making this step easier.

Current behaviour, official builds:

lf -version
r38

Current behaviour, custom build:

lf -version
Built at commit: b12cb33918bb54cf8fcf2c95cf05c58c0981edff 2025-10-27T09:31:00Z
Go version: go1.25.3

Desired behaviour, custom build (open for suggestions):

lf -version
r39 (Unreleased)
Built at commit: b12cb33918bb54cf8fcf2c95cf05c58c0981edff 2025-10-27T09:31:00Z
Go version: go1.25.3

---

Some thoughts: I am unsure how to handle cases where someone clones the official release r38 and then modifies it.

Should it say something like:

lf -version
r38 (Modified)
Built at commit: b12cb33918bb54cf8fcf2c95cf05c58c0981edff 2025-10-27T09:31:00Z
Go version: go1.25.3

I am also unsure about the implementation details. Should the version be a (hardcoded) built-in variable that gets changes as soon as the official release has been out? Should the version number be the release one until the first new change has been merged?

[CatsDeservePets]

What do you think, @joelim-work?

[joelim-work]

The version comes from two places:

1. Latest tag if using the build.sh script:

   https://github.com/gokcehan/lf/blob/b12cb33918bb54cf8fcf2c95cf05c58c0981edff/gen/build.sh#L11

2. If empty then fall back to debug.ReadBuildInfo:

   https://github.com/gokcehan/lf/blob/b12cb33918bb54cf8fcf2c95cf05c58c0981edff/main.go#L193-L222

The latter was added in #1517. In particular, the code was written so that additional build info is not printed out if there is already a version number:

I also considered adding the Go version information to the regular version information, but decided against it in case someone parses the output from the current version command.

---

Now as for your requirements, I don't know if it's possible for go build to detect the latest tag, but this can done in build.sh. With some shell scripting it should be possible to get it into the format r39 (Unreleased). Currently it just uses whatever the latest tag is, you will have to check if the tag is not pointing at the latest commit and modify the version string accordingly.

[Limero]

Now that we have a CHANGELOG.md in the repo, we could embed that file and parse it to achieve this. It would also make it possible to show the changes in the latest release, similar to :help news in Neovim.

However, it would increase the binary sizes, since it would bundle the whole file.

[CatsDeservePets]

Funnily enough, back when CHANGELOG.md was added I also mentioned the idea of :h news.

I think parsing the changelog might be the most accurate way of achieving this.