Skip to content
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

Bump PHP minimum version to 7.2 #16555

Merged
merged 1 commit into from Feb 18, 2021
Merged

Conversation

MauricioFauth
Copy link
Member

PHP officially ended support for PHP 7.2 on 2020-11-30. So it is safe to bump the minimum version to PHP 7.2 for phpMyAdmin 5.2, which is likely to be released only in the second half of 2021.

Related to #15607.

doc/faq.rst Show resolved Hide resolved
Copy link
Member

@williamdes williamdes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉

@williamdes williamdes added this to the 5.2.0 milestone Jan 4, 2021
@williamdes williamdes added this to In progress in pull-requests via automation Jan 4, 2021
@ibennetch
Copy link
Member

ibennetch commented Jan 5, 2021 via email

@MauricioFauth
Copy link
Member Author

MauricioFauth commented Jan 9, 2021

We should continue to support a version for security fixes to help distributions with LTS PHP versions. Would that be phpMyAdmin 5.0 or 5.1?

I thought about having a planned schedule for releases and support.

The following table presents three ideas:

  • Release a minor (or major) version once a year in the fourth quarter.
  • Fully support the release for one year and support it for an additional year for security issues only.
  • Bump the minimum PHP version for each minor release, since PHP releases a minor version per year. Supporting the PHP version for three years after the PHP EOL date.
PMA Initial Release End of Regular Support End of Security Support PHP PHP EOL
4.9 2019-06-04 2019-12-31 2021-12-31 5.5 / 7.0 2016-06-21 / 2019-01-10
5.0 2019-12-26 2020-12-26 2021-12-26 7.1 2019-12-01
5.1 2021 Q1 2022 Q1 2023 Q1 7.1 2019-12-01
5.2 2021 Q4 2022 Q4 2023 Q4 7.2 2020-11-30
5.3 2022 Q4 2023 Q4 2024 Q4 7.3 2021-12-06
5.4 2023 Q4 2024 Q4 2025 Q4 7.4 2022-11-28
5.5 2024 Q4 2025 Q4 2026 Q4 8.0 2023-11-26

If you think that two years of support (regular + security) is too short, we could increase one year of support, either for regular support or for security support.

What do you think about this?

Edit: Changed phpMyAdmin 4.9 "End of Security Support" date and added PHP 7.0 EOL date.

@MauricioFauth
Copy link
Member Author

Additional information:

Debian:

Debian PHP EOL EOL LTS
8 Jessie 5.6 June 2018 June 2020
9 Stretch 7.0 June 2020 June 2022
10 Buster 7.3 ~2022 ~2024

Ubuntu:

Ubuntu PHP End of Standard Support
16.04 LTS Xenial Xerus 7.0 April 2021
18.04 LTS Bionic Beaver 7.2 April 2023
20.04 LTS Focal Fossa 7.4 April 2025
20.10 Groovy Gorilla 7.4 July 2021

Fedora / RHEL / CentOS:

From Remi Collet's comment:

  • Fedora 30/31 have 7.3
  • Fedora 32 will have 7.4
  • RHEL / CentOS 7 have 5.4 (default version) and 7.2 and soon 7.3 (RHSLC 3.4)
  • RHEL / CentOS 8.0 have 7.2
  • RHEL 8.1 have 7.2 or 7.3 (CentOS 8.1 should be released soon)

@williamdes
Copy link
Member

Your release and support table looks good to me !
Another question: why requiring the minor version 5 of 7.2 ?
I chose the .20 for Doctum because of the year it was released

@MauricioFauth
Copy link
Member Author

Another question: why requiring the minor version 5 of 7.2 ?

Twig and Symfony related packages requires 7.2.5, so requiring just 7.2 would not be accurate enough.

@MauricioFauth
Copy link
Member Author

Some reasoning behind the ideas:

Release a minor (or major) version once a year in the fourth quarter.

I think it's good to have a defined release cycle and we already release minor versions once a year. 5.1.0-rc1 in Dec 2020, 5.0 in Dec 2019, 4.8 in April 2018, 4.7 in March 2017. Choosing a quarter of the year for the release seems like a more flexible interval than choosing a month.

Fully support the release for one year and support it for an additional year for security issues only.

Instead of ending regular support when the next minor is released and not knowing when to stop security support, we can be more predictable by doing support for a fixed time. This works better with a defined release cycle.

Bump the minimum PHP version for each minor release, since PHP releases a minor version per year. Supporting the PHP version for three years after the PHP EOL date.

We can bump the minimum PHP version in a predictable way and we can support distributions with LTS PHP versions as well, by staying behind enough with the minimum PHP version.

@Guileas
Copy link
Contributor

Guileas commented Jan 24, 2021

@MauricioFauth I think it's a good idea to have a schedule it would be super useful for everyone!

@codecov
Copy link

codecov bot commented Feb 5, 2021

Codecov Report

Merging #16555 (7e53f9f) into master (d018f78) will increase coverage by 0.11%.
The diff coverage is 0.00%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master   #16555      +/-   ##
============================================
+ Coverage     52.84%   52.96%   +0.11%     
  Complexity    15101    15101              
============================================
  Files           471      471              
  Lines         62582    62212     -370     
============================================
- Hits          33074    32948     -126     
+ Misses        29508    29264     -244     
Flag Coverage Δ Complexity Δ
dbase-extension ? ?
recode-extension 52.61% <0.00%> (+0.17%) 0.00 <0.00> (ø)
unit-7.1-ubuntu-latest ? ?
unit-7.2-ubuntu-latest 52.61% <0.00%> (ø) 0.00 <0.00> (ø)
unit-7.3-ubuntu-latest 57.36% <0.00%> (ø) 0.00 <0.00> (ø)
unit-7.4-ubuntu-latest 57.38% <0.00%> (ø) 0.00 <0.00> (ø)
unit-8.0-ubuntu-latest 57.54% <0.00%> (ø) 0.00 <0.00> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ Complexity Δ
libraries/common.inc.php 0.00% <0.00%> (ø) 0.00 <0.00> (ø)
libraries/classes/Plugins/Import/ImportShp.php 56.49% <0.00%> (-16.24%) 43.00% <0.00%> (ø%)
libraries/classes/Plugins/Export/ExportOdt.php 89.62% <0.00%> (-6.67%) 72.00% <0.00%> (ø%)
libraries/classes/Plugins/Export/ExportOds.php 92.44% <0.00%> (-5.24%) 27.00% <0.00%> (ø%)
libraries/classes/Twig/I18n/NodeTrans.php 93.54% <0.00%> (-1.62%) 25.00% <0.00%> (ø%)
libraries/classes/Plugins/Schema/Eps/Eps.php 72.58% <0.00%> (-1.62%) 16.00% <0.00%> (ø%)
libraries/classes/Theme.php 86.41% <0.00%> (-1.24%) 31.00% <0.00%> (ø%)
...s/classes/Plugins/Schema/Dia/DiaRelationSchema.php 48.19% <0.00%> (-1.21%) 20.00% <0.00%> (ø%)
...s/classes/Plugins/Schema/Eps/EpsRelationSchema.php 47.11% <0.00%> (-0.97%) 21.00% <0.00%> (ø%)
libraries/classes/VersionInformation.php 85.84% <0.00%> (-0.95%) 48.00% <0.00%> (ø%)
... and 111 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d018f78...2b830ea. Read the comment docs.

pull-requests automation moved this from In progress to Reviewer approved Feb 5, 2021
PHP officially ended support for PHP 7.2 on 2020-11-30. So it is safe to
bump the minimum version to PHP 7.2 for phpMyAdmin 5.2, which is likely
to be released only in the second half of 2021.

Related to phpmyadmin#15607

Signed-off-by: Maurício Meneghini Fauth <mauricio@fauth.dev>
@MauricioFauth MauricioFauth merged commit 1dc7093 into phpmyadmin:master Feb 18, 2021
pull-requests automation moved this from Reviewer approved to Done Feb 18, 2021
@MauricioFauth MauricioFauth deleted the php72 branch February 18, 2021 15:43
@MauricioFauth MauricioFauth self-assigned this Feb 18, 2021
MauricioFauth added a commit that referenced this pull request Feb 18, 2021
Bump minimum PHP version to 7.2

Signed-off-by: Maurício Meneghini Fauth <mauricio@fauth.dev>
@williamdes williamdes mentioned this pull request Dec 11, 2021
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
pull-requests
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

4 participants