mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
Steps for v3.3.0 #3085
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#3085
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @sledgehammer999 on GitHub (Sep 16, 2015).
My intention is to release v3.2.4 this Saturday and make it the last of the v3.2.x series. v3.2.5 will be released only if a very bad bug is discovered.
So v3.3.0 release is very near. I'll touch up my pending PRs and merge them. Also there are a few items tagged with the v3.3.0 milestone. Some of those already have pending PRs which will be reviewed and merged. Some of those are "take a closer look to the issue to make sure that you don't do anything wrong. If you discover the bug in the code fix it."
If there are remaining issues, depending on their nature, seriousness and if they can be fixed in a timely manner they will be fixed. Otherwise they will be postponed for 3.3.1 resolution.
My intention is to make Qt5 the default if #2835 is resolved, (there are possible solutions already). I would also drop qt4 but Travis CI will be useless then.
This is a heads up for the team. Please refrain from pushing new PRs. Expect to be ignored if you do. I'll focus to streamline the release.
If there are serious issues to be considered please post them here. Or if you want to make some remarks on the above release plan.
Lastly, I'll try to introduce a new icon theme for this release plus a new approach to the transferlist progressbars. My intention is to make them have the same look and feel across all OSes and themes. There are themes that really break the readability of the list (on the progressbar value) and some that don't even display it (OS X platform). My intention is to use styles and achieve something like this (I'll post screens later): Have the progressbar take all the (rectangle) space available to the tree cell. Use the same color as we do for the text depending on status. Well not exactly the same. Try to apply the necessary effects(eg gradients) to achieve a "flat, smooth and modern" look. The benefits are: a) very good readability since the whole space is used, b) no issues with themes, c) even better color coding by integrating with the rest of the treeview row.
Of course this is a maybe. I cannot estimate now how much time this requires. If it takes too much I'll just release v3.3.0. Also I am not very good with art and design. I may need the help of others, especially the webdevs, to achieve a good color output. Of course I'll provide the initial PR to play with.
@sledgehammer999 commented on GitHub (Sep 16, 2015):
@qbittorrent/qbittorrent-frequent-contributors @Gelmir
@glassez commented on GitHub (Sep 16, 2015):
Fix version in Issue title and description.
@glassez commented on GitHub (Sep 16, 2015):
How about #3685 for v3.3.0? It has no big changes but it opens the door for using modern C++ in new versions of qBittorrent.
@ngosang commented on GitHub (Sep 16, 2015):
I agree. I want #3444 and #3332 reviewed and merged in v3.3.0 if it's possible. Milestone tag? 😄
@txtsd commented on GitHub (Sep 16, 2015):
Will you add a theme that will use current gtk theme icons as a way to match the rest of the system?
Also, as long as you don't add white space, the flat, modern, look will be better. I love material design, but I hate the amount of valuable real estate wasted as needless white space.
@Chocobo1 commented on GitHub (Sep 16, 2015):
#3217, #3230
I've already created these for v3_2_x branch, it'll be a waste to just throw them away, no big changes there, would be great if it can be merged.
looking forward to it but sounds non-trivial. I remember I tried to replace most icons with svg image formats, although it looks great, but it slows down overall performance, probably my impl. was not good enough.
@sledgehammer999 commented on GitHub (Sep 16, 2015):
For current PRs: Some of them will be merged for sure before v3.3.0 but not sure which. The ones I tagged today will be reviewed for merging for sure.
@Chocobo1 your OSX PR might need not make it. Not because you're doing it wrong but because I might decide in a different course of action for OSX behavior. I'll notify you the coming days.
@txtsd On linux qbt will continue to use the applied icon theme. OS X and Windows need some freshing up from the current icons.
@Chocobo1 as a first step I am looking to make png files from the svgs to replace the current ones in name and resolution. And in a later step actually use svg. I am experimenting with "font icon" themes at the moment.
@sledgehammer999 commented on GitHub (Sep 16, 2015):
@txtsd about the white space: As I said I plan to use all the space provided by the treeview cell. Maybe with very little rounding in the corners.
@txtsd commented on GitHub (Sep 16, 2015):
@sledgehammer999 idk what you're talking about. qbt has always used its own ugly oxygen icons regardless of my icon theme and the
use system icon themeoption.And I have no idea what a treeview cell is. A pic would help.
@sledgehammer999 commented on GitHub (Sep 16, 2015):
Can you post a screenshot marking the icons?
It is the rectangle space where a row and a column intersect.
@txtsd commented on GitHub (Sep 18, 2015):
Literally every single icon in the UI.
Screenshots show different icon themes in lxappearance and pcmanfm, while qbittorrent is stuck on the oxygen icons which I don't even have installed.
use system icon themeis checked.@ngosang commented on GitHub (Sep 19, 2015):
@txtsd http://askubuntu.com/questions/100144/how-to-fix-the-look-of-kde-apps-in-lxde
@pmzqla commented on GitHub (Sep 19, 2015):
@txtsd what happens if you start qBittorrent with the following command?
(using some standard paths for the env variable)
Qt simply looks for the icons in the paths defined in that env variable. If the variable is not defined, the fallback icons will be used (in this case oxygen, which are embedded in qBittorrent).
@txtsd commented on GitHub (Sep 19, 2015):
@ngosang I've already used qtconfig-qt4 to set the theme. It doesn't set icons though. And it doesn't work with qbt built with qt5. For qbt3.3.0 to use the gtk theme I have to start it as
qbittorrent --style=gtk+@pmzqla That makes it work! Do I need to export XDG_DATA_DIRS in my .zshrc? And why does qbt not look in those directories by default?
@pmzqla commented on GitHub (Sep 19, 2015):
It's not up to Qt nor qBittorrent to define that variable, it's expected to be set: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
You need to export the variable with the correct content at a "higher" level, if you do that from .zshrc, the variable will be defined only inside your shells. Usually graphic environments are started with scripts and they take care of setting all the XDG_* env variables. I can see this is the case for /usr/bin/startlxde in Debian. There are other ways to do that (
~/.xsessionrcmaybe), but that's something you have to figure out, I don't even know what's your setup.@txtsd commented on GitHub (Sep 19, 2015):
@pmzqla Ah this is probably because I don't use a DE. I run plain old Openbox on Arch. I only use lxappearance with the lxappearance-obconf plugin because it is the easiest way to theme Openbox.
I tried exporting it in
.xinitrcbut that isn't doing the trick either. I figured that would be the highest level.EDIT: Nevermind I got it to work. I was sourcing
.xprofilebefore exportingXDG_DATA_DIRS@glassez commented on GitHub (Oct 25, 2015):
@sledgehammer999 I propose to reduce the range of Issues/PRs for v3.3 to the minimum required, and to postpone the others for next releases.
@sledgehammer999 commented on GitHub (Oct 25, 2015):
Yes, I pretty much consider them "soft dependencies". All the PRs IMO need to get merged. Other than that, only serious stuff should get fixed.
@glassez commented on GitHub (Oct 25, 2015):
IMO, only one major thing left, although it is not marked as v3.3. This is a problem with torrent paths (this leads to data inconsistencies).
@sledgehammer999 commented on GitHub (Oct 25, 2015):
Are you talking about #3847?
@glassez commented on GitHub (Oct 25, 2015):
Yes.
@sledgehammer999 commented on GitHub (Oct 25, 2015):
Yes, I'll review it today after I get back home in a few hours.
@glassez commented on GitHub (Oct 29, 2015):
Offtopic. Don't want to create a separate issue for this.
@sledgehammer999 A lot of pending PRs in recent time and their number is increasing. I see you don't have time to process all of this due to lack of time to do this. Maybe there is a way to help you? Maybe you need to develop some rules for check PRs and delegate some of this work to others?
How do you see the future of the project?
@txtsd commented on GitHub (Oct 29, 2015):
While we're on the topic, once 3.3.0 lands, I propose going through the 1000+ issues, closing old ones, merging dupes, assigning meaningful labels so they can be easily classified, and just generally keeping the list maintained.
@ngosang commented on GitHub (Nov 3, 2015):
@sledgehammer999 could you put in the forum a Windows build for the current master so users can test it before the release?
@sledgehammer999 commented on GitHub (Nov 3, 2015):
I have uploaded one on 28/10/2015. I'll probably do one this weekend too. Anyway, before releasing I'll do 1-2 weeks and RC upgrade to the version string and of course post builds. (This will give time for translators too).
@glassez commented on GitHub (Nov 5, 2015):
@sledgehammer999, Maybe you should separate branch for version 3.3 now to not suspend the merge of pending PRs into master? Or the problem is in your own time, and it still will not accelerate?
@sledgehammer999 commented on GitHub (Nov 8, 2015):
Hey guys, shit has happened in real life and I propose a revision of the v3.3.0 if it is ok with you.
I can troubleshoot in time #3018, #3430 and #3602 and take appropriate action.
I might be able to manually merge/fix #2739. If not, I'll exclude it.
Patch for #588 is ready, but needs more thorough testing and review. It can make it in some later release of v3.3.x.
I can merge #3860 but it'll probably break every single PR out there. Do I proceed?
About my plans: Icons+progress bars: not now, but later in v3.3.x. qt5 bugs: Probably fixable now and switch to qt5 by default.
Is that ok?
@glassez commented on GitHub (Nov 8, 2015):
What does it mean? #2433 is not PR. Besides, this is far from over. So there is no sense to target this issue to any milestone.
@sledgehammer999 commented on GitHub (Nov 8, 2015):
Sorry wrong number. I meant #2739
@ngosang commented on GitHub (Nov 8, 2015):
I think you should let #588 and #3860 for the next version. The rush is not good.
@Chocobo1 commented on GitHub (Nov 8, 2015):
I think #3860 should be merged (immediately) after 3.3.0 is released.
And I also think glassez restructure changes should be merged (immediately, if no major bugs) after a (major/minor) release, note that not all restructure changes should be merged at once but pick 1~3 the most important ones at the time (give a tag to the PR prior maybe).
UPDATE: also would like to see #3961 and #3932 merged.
@glassez commented on GitHub (Nov 9, 2015):
Agree.
I currently have two pending PRs of this kind: #3832 and #4020. And I'm working on the sequel to #4020.
@sledgehammer999 commented on GitHub (Nov 9, 2015):
So for v3.3.1:
v3.3.0:
@Chocobo1 commented on GitHub (Nov 9, 2015):
Changes in #3961 and #3932 are really small, care to merge in v3.3.0?
@sledgehammer999 commented on GitHub (Nov 9, 2015):
Sure, unless @glassez doesn't want to.. (breaks his major PRs)
@glassez commented on GitHub (Nov 9, 2015):
No problem with these changes.
@ngosang commented on GitHub (Nov 9, 2015):
#3856 and #3816? I tested both carefully.
@sledgehammer999 commented on GitHub (Nov 9, 2015):
@glassez ?
@glassez commented on GitHub (Nov 10, 2015):
#3856 is Ok.
I commented on #3816.
@sledgehammer999 commented on GitHub (Nov 22, 2015):
I bumped the version to RC. Next weekend v3.3.0 will be released. I bumped webui API_VERSION to 6. I don't know if there are things in master that weren't published in v3_2_x and warrant increase of API_VERSION_MIN too.
There are 2 pending PRs. @ngosang is unresponsive, but it isn't critical for v3.3.0. The other isn't critical too, but I'll try to review it midweek. (I don't have continuous and easy access to the OS X machine).
@ngosang commented on GitHub (Nov 23, 2015):
@sledgehammer999 I let you comments in 3 PRs. The only thing that's annoying me for this release is #4111. You don't need to know web development to fix that, just change the colors.
@ngosang commented on GitHub (Nov 29, 2015):
@sledgehammer999 I have a question.
There are a ton of bug reports but most of them related to v3.2.X. I think many of the bugs related to v3.2.X releases are already fixed in v3.3.0.
Are you planning to close v3.2.X bug reports?
Should we tag with a label the bug reports for v3.3.0 so we can ignore old bug reports? (I can help you with that if you give me permission).
@sledgehammer999 commented on GitHub (Nov 29, 2015):
After official v3.3.0 we should ask them if they can replicate in that version. If they don't answer we can close it.
Now, v3.3.0 is almost ready. A last minute important discovery remains: https://github.com/qbittorrent/qBittorrent/issues/3602#issuecomment-160421931
@sledgehammer999 commented on GitHub (Nov 29, 2015):
Ok, beginning the release of v3.3.0. This will take a while.
Thanks all for the help.
@sledgehammer999 commented on GitHub (Nov 29, 2015):
Great, Transifex is down!
Murphy's law(paraphrased): "Everything that can fail will fail at the most inconvenient time".
@glassez commented on GitHub (Nov 29, 2015):
👍
@ngosang commented on GitHub (Nov 29, 2015):
@sledgehammer999 right now is online for me.