Skip to content

Changelogs are quite sloppy #82

Description

@Minoru

Hi! I'm an occasional user (both of lc and LLMs overall), but I read every changelog. I find that oftentimes it's much ado about nothing. The changelog is supposed to be a short description of the changes, but little-coder's entries often include a bunch of inconsequential detail.

To pick on the entry from https://github.com/itayinbarr/little-coder/releases/tag/v1.12.0 that pushed me to file this issue:

The status line is documented (# 71 by @ johnzan, first answered by @ charly1r). A new README section explains every field, read off pi's footer.js rather than inferred. Three corrections to the reasonable-looking guess in the thread: the first number is cumulative session input tokens, not current context size; CH is the cache-hit rate of the latest response alone (cacheRead / (input + cacheRead + cacheWrite)), not a session average, which is why it swings; and (auto) specifically means automatic compaction is enabled. A low CH on a long conversation is a real signal — it's exactly what # 73 above was causing.

(I broke backlinks to avoid spamming people with mentions.)

This is about 5 times longer than it should be. Let's take on it in parts.

The status line is documented (# 71 by @ johnzan, first answered by @ charly1r).

This part is good. Nice of you to give credit to people who answer issues.

A new README section explains every field,

Okay, now I know where the new docs are.

read off pi's footer.js rather than inferred.

This is unimportant. I guess the meaning of these words are "trust me, the doc is not made up", but I already assume they aren't made-up, so why boast about it?

Three corrections to the reasonable-looking guess in the thread: [...]

First, this assumes that I read the thread, which I didn't. This assumption is fairly weird. Is it some sort of "star issue" that everybody is supposed to keep abreast of? I never heard of it before.

Second, as I already said, the point of the changelog is to summarise the changes. Linking to an issue and saying "three corrections to it" is not a summary. If the issue is so large it can't be summarised sensibly, just put those "three corrections" in the final comment of the issue and link to it from the changelog.

Third, this sentence is trying to explain parts of the status line. Why? Previous sentences already said there's a new doc in README. There is no need for re-explaining a part of it in the changelog.

A low CH on a long conversation is a real signal — it's exactly what # 73 above was causing.

This one is hard to judge. Considering I don't know what status line indicates, and I haven't read the new doc yet, this sentence tells me pretty much nothing. It looks like a nice tidbit, like "btw this knowledge helps you notice issues like that other one we fixed". Is it important enough to be included in the changelog? I'm not sure.


Ideally, this item should have looked like this:

The status line is documented in the README (# 71 by @ johnzan, first answered by @ charly1r).

where "in the README" is a link to the specific README section.

Thanks!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions