diff options
| author | toofar <toofar@spalge.com> | 2023-12-12 09:05:22 +1300 |
|---|---|---|
| committer | toofar <toofar@spalge.com> | 2023-12-12 09:19:53 +1300 |
| commit | fbb3e10ce10cba6b4cface4e4b0a46b54923d3a4 (patch) | |
| tree | d29de6e0c9f5de0832035fe1b8026f5d44f89af3 | |
| parent | 26f1069d2a793070316124289c4768cfaaa5ac43 (diff) | |
| download | qutebrowser-fbb3e10ce10cba6b4cface4e4b0a46b54923d3a4.tar.gz qutebrowser-fbb3e10ce10cba6b4cface4e4b0a46b54923d3a4.zip | |
Add placeholder changelog entries for next two releases
I would like to make merging PRs lower friction. One aspect of that for
me is having to think about where to add the changelog info, whether it
should go in an existing section, whether I should create a new section,
what the format changelog is supposed to be in. These questions are a
bit coupled with the decision of whether to backport a change or not.
Those aren't hard questions but I don't usually have a long stretch of
time for open source work. So making it so I don't have to make those
decisions at merge time makes it easier for me to fit that work into my
day. Previously it seemed to me that the norm was to only have a future
changelog entry for the next patch release. Occasionally I would merge
stuff and add it to the patch release changelog entry and then think
about how I would have made getting any security fixes out harder or how
it would have to be corrected at backport time. So this is kind of a
pre-commitment that yes, we are going to be merging stuff to main that
won't make it to the next release.
A lot, but not all, of the above rambling will also be mitigated by
adopting a fragment based changelog management system (#7101), because
that means that more of the stuff we have to worry about when merging is
only in the context of the PR. Eg just describe that the change does,
don't worry too much about where that description is going to end up.
Other follow up stuff we could do if norms are established or need
re-enforcing:
* update contributor docs to describe more of the branching strategy as
it applies to merging
* update contributor docs to describe backporting steps and philosophy
* link changelog entries to milestones?
| -rw-r--r-- | doc/changelog.asciidoc | 10 |
1 files changed, 10 insertions, 0 deletions
diff --git a/doc/changelog.asciidoc b/doc/changelog.asciidoc index ab0fa52b2..f9148f76d 100644 --- a/doc/changelog.asciidoc +++ b/doc/changelog.asciidoc @@ -15,6 +15,16 @@ breaking changes (such as renamed commands) can happen in minor releases. // `Fixed` for any bug fixes. // `Security` to invite users to upgrade in case of vulnerabilities. +[[v3.2.0]] +v3.2.0 (unreleased) +------------------- + + +[[v3.1.1]] +v3.1.1 (unreleased) +------------------- + + [[v3.1.0]] v3.1.0 (2023-12-08) ------------------- |