[RFC] gui: Minimum required Qt5 #13478

issue fanquake openend this issue on June 15, 2018
  1. fanquake commented at 3:36 pm on June 15, 2018: member

    With removal of support for Qt4 not far away, opening this for any thoughts on setting a minimum required qt5 version. It could be quite possible for us to support Qt 5.0+.

    Qt4 support was removed in #13458. The current minimum required Qt is 5.2. Set in #14725.

    Qt Versions:

    5.12 (LTS) Supported for 3 years post release. 5.11 Supported until May 2019 5.10 Supported until Dec 2018 (Archived). 5.9 (LTS) Supported until May 31, 2020. 5.6 (LTS) Supported until Mar. 16, 2019 (will end around the same time as the v0.18.0 release).

    Any other releases older than 5.10 are no longer supported (by Qt).

    Qt releases seem to be getting more frequent, and in some cases more aggressive about dropping support for OS versions. i.e macOS >10.12 is required for Qt 5.12.

    Qt Feature Usage:

    There are the following usages of QT_VERSION (excluding bitcoin_qt.m4) in the code:

  2. fanquake added the label GUI on Jun 15, 2018
  3. fanquake added the label Build system on Jun 15, 2018
  4. dongcarl commented at 4:26 pm on June 28, 2018: member
    If releases older than 5.9 are no longer supported (by QT) and it is a LTS release, what would be the rationale for supporting anything <5.9?
  5. MarcoFalke commented at 5:33 pm on June 28, 2018: member
    Many distributions come with older versions of qt, e.g. https://packages.ubuntu.com/xenial/libs/qt5-default
  6. fanquake commented at 6:17 am on July 1, 2018: member

    Per platform Qt minimums was bought up in #13561, suggesting that on macOS the minimum could be bumped to take advantage of Qt’s Mac Extras module, which has been available in >5.2.

    I’m currently -0 on that idea, as I think it’ll lead to complication in the depends system, and the qt portion of the code base.

    However, interested to hear other opinions, and potential advantages of that approach.

  7. droark commented at 6:24 am on July 1, 2018: contributor
    Hello. Regard QtMacExtras, it’s a bit hard for me to say for certain whether or not the pros outweigh the cons. QMacToolBar might be handy for streamlining some Mac-specific code. There could also be some other calls that allow for code optimizations. Would it be worth the pain of adding it to the depends system, though? My gut says yes. The depends system, while a bit verbose, seems to make file adds pretty straightforward. I can take a swing at adding QtMacExtras to the depends system and see how awful it is, and then report back.
  8. Sjors commented at 2:01 pm on July 10, 2018: member

    QT4 was removed in #13458. Depends uses 5.9.6 as per #12971.

    So unless there’s a reason someone can’t use the depends system, it seems safe to set the minimum to 5.9.6.

  9. MarcoFalke commented at 2:54 pm on July 10, 2018: member
    I think 5.2 is a reasonable minimum, since I couldn’t find any distros that come with less than that. Lowest I could find: https://packages.ubuntu.com/trusty/libs/qt5-default
  10. Sjors commented at 1:08 pm on August 2, 2018: member

    There’s a check in ./configure:

    0checking for Qt < 5.4... no
    

    No idea what it’s for, but could potentially be removed depending on which minimum version we pick.

  11. laanwj commented at 8:01 pm on August 28, 2018: member
    due to use of QTimer::singleShot specialization with method pointers, current master is only compatible with qt 5.4 and higher (see #14078)
  12. promag commented at 8:52 pm on August 28, 2018: member
    I’m in favour of bumping to 5.5.
  13. laanwj commented at 8:46 am on August 29, 2018: member

    I’m in favour of bumping to 5.5.

    Any specific reason to choose 5.5 and not 5.4?

  14. promag commented at 8:53 am on August 29, 2018: member

    @laanwj because 5.5 is the version that comes with xenial, trusty EOL is april 2019.

    On the other hand, because of #13529#issue-196954857 we could bump to 5.9 according to the above #13478 (comment).

  15. jonasschnelli commented at 12:50 pm on August 30, 2018: contributor

    Debian 9 “stretch” is on Qt5.7, though Debian 8 “jessie” is “stuck” on Qt5.3.2… Not that it matters, just an indicator.

    For me the questions are more:

    • what does it take to gain again compatibility with Qt5.X?
    • what are the restrictions we take supporting Qt5.X?

    I think we should answer those questions for 5.2 up to 5.5.

    Ideally we should support as far back as possible (below 5.2. makes little sense IMO though). But since this is OSS, if nobody is interested in supporting older Qt versions, so shall it be.

  16. MarcoFalke added this to the milestone 0.18.0 on Sep 11, 2018
  17. MarcoFalke commented at 11:18 pm on September 11, 2018: member
    Assigned 0.18.0 milestone, since we need to decide by then.
  18. MarcoFalke commented at 9:51 am on October 20, 2018: member
    Unless someone works around the current compile failures on master, we’d have to bump to 5.4. (5.5 still works right now)
  19. hebasto commented at 8:25 pm on October 29, 2018: member
    Qt LTS comes with three years standard support. We could afford five years support. Qt 5.2.1 was released on 2013-12-12.
  20. droark commented at 8:31 pm on October 29, 2018: contributor
    @hebasto - I’m a bit confused regarding what you’re trying to say. Who exactly would pay for the LTS extension? Which version do you have in mind? (Assuming I understand things correctly, 5.2.1 LTS with five year support would end on Dec. 12 of this year.) Why would this really matter to Core unless a significant number of people are still using the LTS? Seems unlikely to me but maybe others have good metrics?
  21. hebasto commented at 8:14 pm on November 13, 2018: member
    Official Qt site don’t expose docs for versions from 5.0 to 5.4.
  22. MarcoFalke commented at 8:49 pm on November 13, 2018: member
    Someone could probably start by removing all QT_VERSION > 0x050100 and QT_VERSION >= 0x50200 checks and bumping the minimum version to 5.2, since we surely won’t support less than that.
  23. MarcoFalke added the label Up for grabs on Nov 13, 2018
  24. laanwj referenced this in commit 74213fa4d1 on Nov 14, 2018
  25. fanquake added the label Needs release notes on Nov 14, 2018
  26. fanquake commented at 12:18 pm on November 14, 2018: member
    I’ve updated the parent, and added a needs release notes tag. Still unclear if we’ll bump again before 0.18.0.
  27. MarcoFalke commented at 5:27 pm on November 14, 2018: member

    0.18.0 will be released some time in April next year (#14438), which means that Ubuntu Trusty is EOL (https://wiki.ubuntu.com/Releases)

    So I suggest we bump to 5.4. (or whatever is the smallest version that currently compiles).

    Are there any distros that ship a qt version that is older than Ubuntu Xenials 5.5.?

  28. Sjors commented at 1:54 pm on November 20, 2018: member
    I still don’t understand the rationale for supporting a QT version that’s older than what we include in depends, i.e. 5.9. If anyone really insists on using an ancient Ubuntu version, they can just use the depends system. Unless I’m missing something.
  29. MarcoFalke commented at 4:58 pm on November 20, 2018: member
    @Sjors depends might not work on every os/arch?
  30. fanquake commented at 11:10 am on November 29, 2018: member

    Something else to consider is Qt 5.12s supported platforms, especially if we’d like to use it for 0.18.0.

    Full info here, however the basics are:

    OS Supported Versions
    macOS > 10.12
    Windows 7, 8.1 and 10
    Ubuntu 16.04 and 18.04
    RHEL > 7.4
    OpenSUSE > 43.2
  31. laanwj referenced this in commit 62c15471f1 on Dec 13, 2018
  32. Sjors commented at 2:48 pm on December 17, 2018: member
    So far we’ve bumped the minimum version to 5.2. I suggest having Travis check this, see #14983.
  33. Sjors commented at 12:15 pm on February 11, 2019: member

    See also #15320

    • in practice QT 5.2 doesn’t currently build
    • 5.6 LTS ends around the time we release v0.18.
    • Travis checks only as far back as 5.5 (on Xenial)

    So I think bumping to 5.5 makes sense, unless:

    • we get a 5.4 build working on e.g. Trusty by fetching an old binary; or
    • we can fix 5.2 and build the GUI on Trusty
  34. fanquake commented at 1:20 pm on February 11, 2019: member
    I’ve updated the top comment here. My current thought is a Qt 5.6 minimum requirement.
  35. Sjors commented at 1:48 pm on February 11, 2019: member
    ACK 5.5 <= x <= 5.9.7, lower only if Travis checks it
  36. MarcoFalke commented at 1:55 pm on February 11, 2019: member
    Ok, please someone bump it to 5.5. We are just walking in circles with those discussions.
  37. MarcoFalke commented at 1:56 pm on February 11, 2019: member

    My current thought is a Qt 5.6 minimum requirement.

    5.6 wouldn’t work because xenial still uses 5.5 and removing that would require some workarounds for the ppa as well as people building on xenial.

  38. jonasschnelli closed this on Feb 14, 2019

  39. jonasschnelli referenced this in commit 3b33cbc2b6 on Feb 14, 2019
  40. MarcoFalke removed the label Needs release note on Mar 5, 2019
  41. MarcoFalke removed the label Up for grabs on Mar 5, 2019
  42. lucayepa commented at 11:54 pm on March 27, 2019: contributor
    Is it supposed to stop during configure, correct? If so, I think there is something not working, because I tested it on a system with QT 5.3.2 and it doesn’t stop during configure. Instead it stops during compilation with an error that is not explicative at all. Let me know if this is an issue. Maybe it’s only a nit, not worth to be filed as issue.
  43. MarcoFalke commented at 12:45 pm on March 28, 2019: member
    @lucayepa Yes, please file a separate issue about that
  44. lucayepa commented at 6:12 pm on March 28, 2019: contributor
    Ok. Just filed #15688 .
  45. 10xcryptodev referenced this in commit 4c82a08931 on May 14, 2020
  46. 10xcryptodev referenced this in commit c539cc6397 on May 14, 2020
  47. 10xcryptodev referenced this in commit 6ff92ca28f on May 15, 2020
  48. 10xcryptodev referenced this in commit 6ed2e97423 on May 15, 2020
  49. 10xcryptodev referenced this in commit 61049926a0 on May 17, 2020
  50. 10xcryptodev referenced this in commit 9c9367efb3 on May 17, 2020
  51. 10xcryptodev referenced this in commit 51d3507318 on May 20, 2020
  52. 10xcryptodev referenced this in commit 8ef5bc4ad4 on May 20, 2020
  53. 10xcryptodev referenced this in commit 5debbf307b on Jun 12, 2020
  54. 10xcryptodev referenced this in commit 76cfc7c912 on Jun 12, 2020
  55. gades referenced this in commit 2667681922 on Jun 27, 2021
  56. gades referenced this in commit 0959261b18 on Jun 27, 2021
  57. Munkybooty referenced this in commit e5ce8bad44 on Aug 8, 2021
  58. Munkybooty referenced this in commit 67690c21c9 on Aug 11, 2021
  59. Munkybooty referenced this in commit 3e3809517d on Aug 11, 2021
  60. Munkybooty referenced this in commit b1688e6fc7 on Aug 13, 2021
  61. Munkybooty referenced this in commit f8aa222ba3 on Aug 15, 2021
  62. MarcoFalke locked this on Dec 16, 2021
  63. gades referenced this in commit 6ef6812ec4 on Feb 23, 2022

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-17 09:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me