Update CHANGELOG.md

[dati18]

No description provided.

[outdooracorn]

I think it would be useful to document how you created this changelog in the commit message.

[outdooracorn]

How come this is 0.3.137 but all the later tags are still 0.3.135?

[dati18]

it's from 2024... I don't know what decision was made here? :(

[dati18]

check this out: https://github.com/wbstack/queryservice/tags

[outdooracorn]

I don't know what decision was made here

I believe it is within your capabilities to find it out.

check this out: https://github.com/wbstack/queryservice/tags

Which part specifically would you like me to check out? That is just a page of tags and the commit message of the referenced commit. What conclusion have you drawn by looking at that page?

Please find out the reason why this is the only 0.3.137-* tag and update the changelog with a useful summary for the next reader.

[outdooracorn]

We should use the Imperative mood here. E.g. "Merge" instead of "Merged".

I would also like to see some more details here. Some potential things that might be useful to say (I'm not sure as I haven't looked):

• Why do these updates require a new release?
• What do the GitHub actions that you are updating do?
• Are there any particularly interesting or risky updates?

[dati18]

I can list all the github action dependabot's bumps. But I don't think it's necessary to add more information :)
The updates requires a new release due to the way we configured our queryservice's helmfile setting to take the release tag instead of the commit hash, there is no need to repeat this information.
https://github.com/wmde/wbaas-deploy/blob/7c7a3fe7727259ca3bf4463c91cecab894e67dea/k8s/helmfile/env/staging/queryservice.values.yaml.gotmpl#L2

[outdooracorn]

Listing all the GitHub Action Dependabot updates probably isn't that useful for a changelog.

What I am interested in, and would like to have written in the changelog for future readers, is why have we created a new tag when there are no changes to the code or the container image? The changes that have been made only affect the build pipeline.

How about adding something like this:

- Update GitHub Actions dependencies
  - Create a new tag to be able to test the dependency updates to the build process hasn't negatively affected the built image

[outdooracorn]

This and the other merge commit aren't very useful information in the changelog. The changelog shouldn't be a copy of the git history, that already exists for people to look at if they want. This should be a more useful human-readable update about what has changed in each new release.

[dati18]

I just copied them from the release logs :( and it's a year old

[outdooracorn]

I looked into this some more, and we don't actually have any releases (see https://github.com/wbstack/queryservice/releases). We only have tagged commits (see https://github.com/wbstack/queryservice/tags). Is this what you meant by "release log"?

The text you see with each tag in the GitHub interface isn't a release note; it is the commit message of the commit the tag is referencing. It only contains that one commit message; not, for example, all the commit messages since the last tag.

For instance the text you see with the 0.3.135-wbstack.3 tag is:

Merge pull request #113 from egonw/patch-1

Updated the URL of the WikiPathways SPARQL endpoint

However, looking at the git history we can see there was more than just that commit since the last tag:

The same is true of the 0.3.135-wbstack.5, 0.3.135-wbstack.4, 0.3.135-wbstack.2, and 0.3.135-wbstack.1 tags.

IMO a changelog (or release notes) should be providing a useful, human-readable, summary of the changes that have happened since the last change/release/tag and, if necessary, highlighting any breaking changes. Otherwise, the changelog is not providing any more value than the git history and there isn't much point in having one.

Providing only the last commit for each tag in the changelog is likely worse than not having a changelog as it gives readers a false understanding of the changes that have happened.

Looking at #113 we can see that all the useful information about this change ("Updated the URL of the WikiPathways SPARQL endpoint") is included in the changelog. The "Merge pull request #113 from egonw/patch-1" line provides little useful information to the reader. Please remove these merge commit lines from the changelog.

---

I just copied them from the release logs :( and it's a year old

I don't find this a valid rationale.

Hopefully I have provided you with a good explanation of why this isn't sufficient and what I am expecting from a changelog. If anything is unclear, you would like further explanation, or you're unsure how to proceed, please ask for some guidance.

The git history doesn't get deleted after a year. You are a developer, you are able to analyse a git repo to figure out what code changes that have happened. The commit messages and linked tasks should provide why they happened (granted our commit messages in the past haven't been very good which can make things harder; we should also strive to improve in this area, at least for the commits that end up on the main branch).

[outdooracorn]

FYI, given that we haven't updated this changelog for most of the previous tags, I don't think this PR is required to be merged in order to tag and test these Dependabot changes as part of T418868.

While this PR isn't ready to be merged yet, I'm really happy that you noticed this changelog was outdated and took the initiative to update it. Kudos!

[outdooracorn]

I looked into this some more, and we don't actually have any releases (see https://github.com/wbstack/queryservice/releases). We only have tagged commits (see https://github.com/wbstack/queryservice/tags). Is this what you meant by "release log"?

The text you see with each tag in the GitHub interface isn't a release note; it is the commit message of the commit the tag is referencing. It only contains that one commit message; not, for example, all the commit messages since the last tag.

For instance the text you see with the 0.3.135-wbstack.3 tag is:

Merge pull request #113 from egonw/patch-1

Updated the URL of the WikiPathways SPARQL endpoint

However, looking at the git history we can see there was more than just that commit since the last tag:

The same is true of the 0.3.135-wbstack.5, 0.3.135-wbstack.4, 0.3.135-wbstack.2, and 0.3.135-wbstack.1 tags.

IMO a changelog (or release notes) should be providing a useful, human-readable, summary of the changes that have happened since the last change/release/tag and, if necessary, highlighting any breaking changes. Otherwise, the changelog is not providing any more value than the git history and there isn't much point in having one.

Providing only the last commit for each tag in the changelog is likely worse than not having a changelog as it gives readers a false understanding of the changes that have happened.

Looking at #113 we can see that all the useful information about this change ("Updated the URL of the WikiPathways SPARQL endpoint") is included in the changelog. The "Merge pull request #113 from egonw/patch-1" line provides little useful information to the reader. Please remove these merge commit lines from the changelog.

---

I just copied them from the release logs :( and it's a year old

I don't find this a valid rationale.

Hopefully I have provided you with a good explanation of why this isn't sufficient and what I am expecting from a changelog. If anything is unclear, you would like further explanation, or you're unsure how to proceed, please ask for some guidance.

The git history doesn't get deleted after a year. You are a developer, you are able to analyse a git repo to figure out what code changes that have happened. The commit messages and linked tasks should provide why they happened (granted our commit messages in the past haven't been very good which can make things harder; we should also strive to improve in this area, at least for the commits that end up on the main branch).

[outdooracorn]

I don't know what decision was made here

I believe it is within your capabilities to find it out.

check this out: https://github.com/wbstack/queryservice/tags

Which part specifically would you like me to check out? That is just a page of tags and the commit message of the referenced commit. What conclusion have you drawn by looking at that page?

Please find out the reason why this is the only 0.3.137-* tag and update the changelog with a useful summary for the next reader.

[outdooracorn]

Listing all the GitHub Action Dependabot updates probably isn't that useful for a changelog.

What I am interested in, and would like to have written in the changelog for future readers, is why have we created a new tag when there are no changes to the code or the container image? The changes that have been made only affect the build pipeline.

How about adding something like this:

- Update GitHub Actions dependencies
  - Create a new tag to be able to test the dependency updates to the build process hasn't negatively affected the built image