Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Changelogs and Tags #197

Open
aj-foster opened this issue Jun 26, 2023 · 0 comments
Open

Changelogs and Tags #197

aj-foster opened this issue Jun 26, 2023 · 0 comments

Comments

@aj-foster
Copy link

Hello there πŸ‘‹πŸΌ

This is a general request related to the project's changelog, tags, releases, etc. β€” I'll explain it in narrative form and offer some suggestions of how the maintainers of the library could make my life easier as a consumer.

tl;dr A detailed and up-to-date changelog, and/or tags for all releases, would be very helpful! I understand that library maintenance is extremely time-consuming, but as a consumer, I'm unqualified to determine whether updating this package will break my application.


Today I noticed one of our application's dependencies is using a retired version, so it's time to do a round of updates. I usually do patch package updates at the same time for efficiency. This library has an available update:

# mix hex.outdated
libcluster              3.3.2       3.3.3       Update possible

That's a patch update, so chances are it won't break anything, but I always read the changelog to be sure!

Unfortunately, it doesn't have clearly-labeled information about the past three releases:

# Changelog

## Unreleased

- Use new cypher names
- Allow Epmd strategy to reconnect after connection failures
- Detect Self Signed Certificate Authority for Kubernetes Strategy
- Remove calls to deprecated `Logger.warn/2`

### 3.3.0

...

In this situation, I fall back to manually reading the changes because Elixir is (in my opinion) relatively easy to read. So we're interested in the changes between the 3.3.2 and 3.3.3 releases. The releases page is my usual way of doing this: (1) find the 3.3.3 tag and click on it, (2) use the Compare option in the left, and (3) choose the 3.3.2 tag. Thanks to GitHub auto-generating releases for all tags, this usually works even if the maintainer didn't create a formal release on GitHub with notes.

Unfortunately, the older release doesn't have a tag:

image

That's unfortunate, so we'll have to find the commit that represents the 3.3.2 release manually and use my knowledge of GitHub URLs to create a comparison between that commit and the latest tag. However, when we look at the commits, there's no indication of which one relates to the release:

image

Perhaps the 3.3.1 commit/tag is the same, and that's why this situation occurred. That would be fine, but unfortunately this is opaque to me as a consumer.


This incident isn't big enough to be worth posting about, but it has occurred a few times now. I can say with certainty that the maintainers of this library are by far smarter and harder-working than me. Unfortunately, it can be difficult to use the fruits of this labor because of release-related documentation. ❀️

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant