-
Notifications
You must be signed in to change notification settings - Fork 270
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
Create GitHub releases with changelogs #652
Comments
Hello Lukas and thanks for the report! This is an interesting idea. A changelog is already maintained in CHANGELOG.rst, so it would duplicate the process of writing entries (unless there's an automatic way of copying the former into the latter when tags are pushed), which I don't like because it can be error-prone and doubles the manual work. If we need to choose between CHANGELOG.rst and entries on the tags page specific to GitHub, I prefer the CHANGELOG file: it's more standard, it's present outside GitHub (on PyPI, in wheels and sdist files...), and this repo might not always stick to GitHub.
From what I read, this is either a manual process (one needs to create tags using the GitHub web interface), or you need a GitHub Enterprise Server instance. Is there a GitHub option to automatically fill GitHub releases notes when I |
Hey Adrien, as far as I know, Renovate and Dependabot as well are not able to parse those CHANGELOG.rst files. Regarding your concerns about doubling the manual work, I suggest automating the whole release process. A GitHub action could do the work of writing the CHANGELOG.rst and the release notes for you. Furthermore, automation would replace manual uploads to PyPi or wherever you want to release this package. Automating the whole process would lead to more transparency as every user could see how the package was built. If you are building and uploading the package manually using your computer you could inject malware or something else and we as end-users cant be sure whether the library is safe or not. Building and publishing using CI/CD immensely increases the security of the supply chain.
You cited the enterprise documentation but the changelog generation feature is available for free users as well on Github.com. (see here) |
Maybe I missed something, but the GitHub action and documentation you reference doesn't seem to apply to yamllint: our changelogs are not just the list of commit titles between 2 tags, it's a writing work that tries to be clear, concise and readable, and that a bot wouldn't do. I understand such automation is valuable for large projects with hundreds of commits in each release, but this is not the case here. I think that yamllint users should read the human-written CHANGELOG.rst rather than a bot-generated list. |
In my opinion, every entry in yamllint's Automation is valuable for every project. The time automation safes could be invested into fixing bugs or developing new features. |
I understand. I suggest looking at yamllint commits between the last release and the one before, and to compare to the changelog. Although yamllint commits are atomic and their titles aim to be clear and well redacted (and previously used conventional commits specification), many of them would just burden the changelog and make it less useful and a pain to read. For example, between v1.34.0 (last release) and v1.33.0 there were 38 commits, vs. 6 entries in the CHANGELOG.rst. Some of the commits are just style-related, some commits were merged then unfortunately reverted, some documentation edits should be in the changelog but some others shouldn't, etc. About automation, it's another subject, which I don't want to set-up for this project now. |
I got your point. A well-written changelog is better than a generated one with unnecessary messages. Nonetheless, this project could significantly benefit from creating GitHub releases. By doing so, you enable automation tools like Renovate to parse the changelog and, if desired, publish binaries alongside the release. This approach enhances transparency and makes it easier to browse release changelogs. |
Beyond just tagging, creating GitHub releases and including a changelog would be beneficial. This practice significantly helps users using automation tools such as Renovate or Dependabot. These tools can automatically append changelogs to the merge requests they open, thereby enhancing the efficiency and security of version updates.
GitHub can automatically generate changelogs for releases.
Furthermore, it is probably a good idea to automate the complete release process. For this process a tool like release-drafter could be used.
The text was updated successfully, but these errors were encountered: