Update Changelog for v5.0.0

[sledgehammer999]

Draft for reviewing the changelog for the upcoming RC1 release.
I have left the commit hashes alongside each entry for quicker review.

Let me know if something shouldn't be in the changelog. Or if I have forgotten something. Or if some entry is already backported to v4.6.x.

PS: I mention only entries that make sense to the end user and not internal refactoring.

[glassez]

Keep in mind that I have tried to make sure that all PRs related to the 5.0 branch have a corresponding milestone assigned, while the backported ones have a different ones. So it makes sense to compare this Changelog with the list of PRs having 5.0 milestone assigned.

[glassez]

Keep in mind that I have tried to make sure that all PRs related to the 5.0 branch have a corresponding milestone assigned, while the backported ones have a different ones. So it makes sense to compare this Changelog with the list of PRs having 5.0 milestone assigned.

#19333 Change default power management to Gnome Session Manager
#19404 Remove column span
#19633 Revamp tracker list widget
#19801 Delay subsequent requests to the same host
#19957 Follow the parent category options
#19969 Fix JS memory leak
#20028 Add a class to represent a tag
#20207 Revise conditional for when to use QCollator
#20283 Change "metadata received" stop condition behavior

This is a list of those changes that should also be mentioned (perhaps by changing the titles to more suitable for showing to the end user).

[sledgehammer999]

I had reviewed most of these and the reasons I have not included them:

#19333 Change default power management to Gnome Session Manager

I don't think this changes much from a user POV. It seems like a code cleanup mostly.

#19404 Remove column span

Backported with c7dfc1d

#19633 Revamp tracker list widget

Kinda folded into the entry FEATURE: Improve tracker entries handling

#19801 Delay subsequent requests to the same host

This might be legit. Needs better wording for end user.

#19957 Follow the parent category options

OK, now that I opened the PR I realize that is a feature implementation, not an internal bug fix.

#19969 Fix JS memory leak

Backported with 081eace

#20028 Add a class to represent a tag

From the title it is clearly internal code refactoring. However, it actually fixes a bug aka #19744, so I'll mention that.

#20207 Revise conditional for when to use QCollator

IMO, meaningless for end user.

#20283 Change "metadata received" stop condition behavior

Do you think it is relevant to end users?

[glassez]

#20207 Revise conditional for when to use QCollator

IMO, meaningless for end user.

#20283 Change "metadata received" stop condition behavior

Do you think it is relevant to end users?

They both fix the problems reported by end-users.

[glassez]

Draft for reviewing the changelog for the upcoming RC1 release.

Do you intend to omit the alpha/beta releases?
I would provide at least one beta.

[sledgehammer999]

Do you intend to omit the alpha/beta releases?
I would provide at least one beta.

Sorry, I didn't communicate this well.
With this release cycle I don't want to fumble between alpha/beta/RC designators. I want to choose one designator and monotonically increase it (eg beta1, beta2).
I probably should choose beta as the middle ground. alpha indicates very early dev release ("here be dragons") and RC indicates very stable, almost ready for final release.

[glassez]

alpha indicates very early dev release ("here be dragons") and RC indicates very stable, almost ready for final release.

I agree that there is not much point in releasing an alpha version (we can consider builds from GitHub as intended for alpha testing). But it makes sense to distinguish between beta and RC releases. I would still provide at least one RR, which should mark the creation of v5.0 branch and so-called "feature/strings freeze".

[glassez]

@sledgehammer999
BTW, some bugs are fixed indirectly by fixing libtorrent. E.g. #20006.
Shouldn't we mention such fixups in any way?
The Changelog doesn't seem to be the right place to do this. But in the announcement on the website, they could be mentioned to notify users.

[sledgehammer999]

I pushed the suggested changes as a separate commit to ease review.

which should mark the creation of v5.0 branch and so-called "feature/strings freeze".

👍

#20207 Revise conditional for when to use QCollator

IMO, meaningless for end user.

#20283 Change "metadata received" stop condition behavior

Do you think it is relevant to end users?

They both fix the problems reported by end-users.

I propose that those 2 PRs to be backported instead. What do you think?

[glassez]

I propose that those 2 PRs to be backported instead. What do you think?

I have no serious objections. However, it is worth pointing out that #20283 affects strings, so you will have to make sure that translators have the opportunity to take care of them.

[sledgehammer999]

Two new commits. One addresses the comments and the other mentions the new commits from master.
I have left out PR #20465 #20463 #20442 because I am not sure if they'll be backported or not.

[Chocobo1]

I have left out PR #20465 #20463 #20442 because I am not sure if they'll be backported or not.

As for #20465, if it can be cherry-picked cleanly into v4.x then I'm ok with it.

[sledgehammer999]

PR #20465 is backported in #20498
I think PR #20463 isn't eligible for changelog mentioning (at least I can't think of a descriptive entry) and PR #20442 is included in this PR via an updated commit.

@glassez @Chocobo1 let me know if I can go ahead with the Changelog entries as presented in this PR (minus the commit hashes).

[glassez]

Is it applied to entire WebUI?

[sledgehammer999]

I think so. The PR is #19901

[sledgehammer999]

I rebased on master, I addressed the comments and added entries for the new commit.

[sledgehammer999]

If there isn't any other comment, I am going to merge the Changelog sometime in the next ~12 hours.

[glassez]

If there isn't any other comment, I am going to merge the Changelog sometime in the next ~12 hours.

So can we still leave it open to add new changes as soon as they are merged?

[sledgehammer999]

So can we still leave it open to add new changes as soon as they are merged?

I am not sure what workflow you propose here.
Personally, I wanted to merge this so I could maybe do a beta release the weekend.

[glassez]

I am not sure what workflow you propose here.

1. PR with changes than need to be mentioned in Changelog is merged
2. Commit that adds new Changelog entry is added here
3. Repeat until release

[sledgehammer999]

I have pushed current Changelog, changed version numbers and tagged a beta release. I haven't done the builds yet. I'll do them tomorrow based on the tag.
You can continue pushing into master and maybe create a new draft PR to keep track of Changelog updates.