Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Add CHANGELOG #391

Merged
merged 1 commit into from
May 3, 2024
Merged

Add CHANGELOG #391

merged 1 commit into from
May 3, 2024

Conversation

findjigar
Copy link
Contributor

@findjigar findjigar commented Feb 7, 2024

Fixes #382

@dzmpr
Copy link

dzmpr commented Feb 8, 2024

Why not provide this file to release action?

bodyFile: An optional body file for the release. This should be the path to the file.

@findjigar
Copy link
Contributor Author

Why not provide this file to release action?

bodyFile: An optional body file for the release. This should be the path to the file.

I'm okay with manual effort for now. Will discuss automation later depending on how frequently we change features. We might also work on automatic release notes generation based on commit messages. For now, manual changelog is enough to satisfy the expectation of the community.

@dzmpr
Copy link

dzmpr commented Feb 9, 2024

For now, manual changelog is enough

You plan to copy changelog for every release? It's inconvenient to keep the changelog only in code. F.e. to check the changelog for older versions you need to find the corresponding commit in the repository , rather than just read it from the release post.

@dzmpr
Copy link

dzmpr commented Feb 9, 2024

I don't see any ambiguity in the decision to publish the release notes. Generating them based on commits is a separate step that can be done later. But publishing notes from the file are the minimum for comfortable use of the library.
So far, no differences between versions 1.x.x and 2.x.x have been published anywhere. It is not clear to users what to expect from the new version and how to migrate to it. That's why we within the team are still using version 1.2.3.

@findjigar
Copy link
Contributor Author

I don't see any ambiguity in the decision to publish the release notes. Generating them based on commits is a separate step that can be done later. But publishing notes from the file are the minimum for comfortable use of the library. So far, no differences between versions 1.x.x and 2.x.x have been published anywhere. It is not clear to users what to expect from the new version and how to migrate to it. That's why we within the team are still using version 1.2.3.

Adding older changelog manually is not in scope for this PR. Also, not possible through release action, as older releases doesn't have accurate notes for all versions.

For now, you can go through our docs (https://kermit.touchlab.co/docs/) and Kermit samples to try out the newer version.

@findjigar
Copy link
Contributor Author

For now, manual changelog is enough

You plan to copy changelog for every release? It's inconvenient to keep the changelog only in code. F.e. to check the changelog for older versions you need to find the corresponding commit in the repository , rather than just read it from the release post.

No. changelog would be available moving forward.

@dzmpr
Copy link

dzmpr commented Apr 25, 2024

So, how much more time needed to add changelog?

@findjigar findjigar merged commit 3bc8ab4 into main May 3, 2024
2 checks passed
@findjigar findjigar deleted the jb/changelog branch May 3, 2024 17:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Kermit changelog
3 participants