#7350 closed enhancement (fixed)
Drop support of WordPress 4.2
Reported by: | slaFFik | Owned by: | boonebgorges |
---|---|---|---|
Milestone: | 2.8 | Priority: | normal |
Severity: | major | Version: | |
Component: | Core | Keywords: | |
Cc: |
Description
And start developing for WordPress 4.3+.
Reason: WordPress 4.2 market share is below 5% https://wordpress.org/about/stats/, and according to our declared WordPress version compatibility (https://codex.buddypress.org/getting-started/wordpress-version-compatibility/) we are dropping support of WordPress 4.2.
WordPress 4.3 was released on August 18, 2015.
TODO:
- remove from travis matrix,
- try to find code that is written as a workaround for an older WordPress version.
Attachments (2)
Change History (8)
#2
@
8 years ago
Updating the minimum version just means we need to update the Travis-CI config, as well as the minimum version number in the plugin header. Unlike the change associated with supporting PHP 5.3 as that minimum version, changing the minimum WordPress version does NOT mean we can or should break backwards compatibility.
From https://codex.buddypress.org/getting-started/wordpress-version-compatibility/, emphasis mine:
By extension: When we “drop support” for a version of WordPress, it means we stop including it in our builds, stop answering support questions related to that specific WP version, and stop putting function_exists() checks (and the like) targeting that version when building new BP features. *Dropping support does not mean that we will actively try to break older versions of WP*
#3
follow-up:
↓ 5
@
8 years ago
In my last sentence in description I meant exactly this: "stop putting function_exists() checks (and the like) targeting that version when building new BP features". So basically remove those function_exists()
if any.
Or did I misunderstand this?
#5
in reply to:
↑ 3
@
8 years ago
- Resolution set to fixed
- Status changed from new to closed
https://bpdevel.wordpress.com/2016/11/17/2349/
In my last sentence in description I meant exactly this: "stop putting function_exists() checks (and the like) targeting that version when building new BP features". So basically remove those function_exists() if any.
Or did I misunderstand this?
The emphasis here is "*when building new BP features*". I don't think it's necessary to take the time to go through and find all existing spots. Only when removing the back compat code will greatly increase code quality or performance should we bother doing it proactively. The rest will be naturally refactored out over the course of time.
+1