-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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 to document project changes #7925
Comments
Adding a bit more context. Places where we currently publish a list of changes:
We currently maintain an XML-based changelog that is used for the in-app changelog and is published on the web. Theoretically it supports translations. But in practice it's not happening because of missing tooling support. During a release we manually create a text file containing the list of changes for F-Droid (see app-metadata/…/changelogs/). We currently ignore character limits. These files can be translated via Weblate. However, we currently don't hold a release until the release notes are translated. The text file is used as a base for the release notes on Google Play. If necessary the list is manually trimmed down until it satisfies Google Play's character limit. Things we've talked about, but haven't decided on (as far as I remember):
Ideally, we only want to maintain one changelog and generate the others from that single source. Since there's a character limit on the app store release notes and we don't want to limit ourselves to that, we need a way to flag important entries so tooling can extract only those entries when generating the app store release notes. That tooling would also need to make sure all flagged entries combined don't exceed Google Play's character limit. |
While your right that we need to solve all this questions, this issue aims to reduce workload during release preparation. It will allow us to shift the creation of a changelog from the release preparation to earlier in the development cycle, by updating it on a regular basis. It will be the base to generate all the different variations with their own limitations and requirements in a separate step. |
If the only goal right now is to incrementally build up the changelog during the development cycle, we can use the existing XML file. Example: <?xml version="1.0" encoding="utf-8"?>
<!-- … -->
<changelog>
<release version="next" versioncode="39002" date="unreleased">
<change>Fixed a bug</change>
</release>
<release version="6.901" versioncode="39001" date="2024-05-15">
<change>Fixed a crash when opening the screen to compose a message</change>
</release>
<!-- … -->
</changelog> Without having a clear idea of what we want to support eventually, it's hard to tell if "Keep a Changelog" is a suitable file format. Introducing it now only as a source to manually copy from during the release process doesn't feel like an improvement. We can have the "update changelog during development" feature without it. |
I'm confused as we talked about this and we decided to move on with this approach. Please raise your concerns early on during the planing session. |
Open questions that I think need to be answered before selecting a file format:
It's fine if we want to defer answering these questions until later. But we shouldn't introduce a new file format if we don't have the answers. Building up the changelog incrementally doesn't require answers to all these questions. We can use the existing XML file now and still switch to a different format once we have the answers. |
We want to introduce a changelog for Thunderbird for Android and K-9 Mail. It will serve as a base for creating the project’s release notes and document user facing version changes.
We will follow the specification provided by Keep a Changelog, which is widely used to document project changes. The specification provides a standardized format for maintaining changelogs.
Current state (2024-06-18):
We use the existing xml based changelog and update it reqularly until we have a ticks all the boxes version. This means:
The text was updated successfully, but these errors were encountered: