Skip to:
Content

BuddyPress.org

Opened 5 years ago

Closed 4 years ago

Last modified 3 years ago

#6258 closed idea (fixed)

Update supported WordPress versions

Reported by: DJPaul Owned by:
Milestone: 2.4 Priority: low
Severity: normal Version:
Component: Core Keywords: 2nd-opinion
Cc:

Description

Can we increase the minimum supported WordPress versions? We currently say we're supporting 3.6 upwards. I'd like to propose n-1 (the current version, minus one), which I'm pretty sure we used to do something like, a few years ago. So right now, that's 4.0 onwards.

Why?

  • Less complicated test matrix for Travis-CI; faster overall test completion.
  • Why support outdated, likely insecure, WordPress versions?

Attachments (2)

6258.1.diff (718 bytes) - added by netweb 4 years ago.
6258.2.diff (901 bytes) - added by netweb 4 years ago.

Download all attachments as: .zip

Change History (23)

#1 @boonebgorges
5 years ago

WordPress 4.0 was released on September 4, 2014. The n-1 suggestion would mean that we are sometimes dropping support for versions of WP that were current less than 4 months earlier. This seems pointlessly aggressive. Anyone who has managed WordPress installations in corporate or university environments knows that update cycles sometimes have to be slower than this. (On a related note, I think that security is a red herring here - security patches are almost always applied to the last four or five release series, even when it's not advertised.)

I agree that we don't need to go out of our way to support old versions. For instance, if we decided to use WP_Date_Query for something critical, I don't have a problem with bumping minimum version support to 3.7 (when WP_Date_Query was introduced). In general, the amount of effort we should put into supporting a particular legacy version of WP goes down as we go back in time. (And actually, I'm now remembering that we support date queries for activity, but we do a class_exists() check. IMO this is a minimal compatibility check and thus is a no-brainer, but if other people hated it, I think it'd be fine to drop 3.6 support now.)

If it ain't broke....

#2 @netweb
5 years ago

Copy and paste of comments in #6174:

Replying to johnjamesjacoby:

Replying to netweb:

What versions of WordPress does BuddyPress support?

Currently it's 3.6: Requires at least: 3.6, nothing explicitly comes to mind requiring the bump in required version, except for an opportunity to remove a or a couple of older versions (3.7 & 3.8) from Travis CI speeding up CI reporting.


I'd selfishly like to bump this for these reasons, but I think a few others see it as a badge of honor. Let's revisit this in 2.3.
I agree with this, it is an honour, and I am selfish also!

In particular this, BP currently supports WP 3.6, it was simply far too complex to include it in the test matrix.

P.s. For reference, WP 3.6 was only removed from the Travis CI testing as it was going to be to complex to configure the pre and post switch to WordPress' new "develop" repo with /src and /build folders, see r8017.

We could adjust the build matrix down significantly without changing the supported version.

Rather than testing every version of PHP with every version of WordPress we could limit for example WP3.7 & PHP5.2, WP3.8 & PHP5.3, this would remove 8 jobs from each build, coming up with an ideal/optimal matrix is the hardest part of this decision.

#3 follow-up: @boonebgorges
5 years ago

Who cares if our CI builds are slow? Obviously we don't want them to take days, but the difference between 20 minutes and 10 or 5 minutes is not significant enough that it should influence decisions about the software requirements.

#4 @DJPaul
5 years ago

I'm now remembering that we support date queries for activity, but we do a class_exists() check.

This is exactly the sort of thing I would not want us to start doing more in BuddyPress. It's one of the things I had a vague recollection of when I started to write this ticket, but I couldn't find it searching the code easily).

I think we should at the least change the minimum supported version to 3.7, so we can remove the above class_exists, but also because we have not been running unit tests against 3.6 for almost a year: r8017

I would also support increasing the minimum supported version to 3.8 because we have a line in the Travis-CI config where we have to disable WP_DEBUG with PHP >= 5.4 because of the ext/mysqli deprecation in PHP, but I understand this is a harder sell because I don't think we've yet introduced features that rely on 3.8 code.

#5 in reply to: ↑ 3 @johnjamesjacoby
5 years ago

  • Component changed from Not sure to Tools - Code Improvement
  • Keywords 2nd-opinion added
  • Milestone changed from Awaiting Review to 2.3
  • Priority changed from normal to low
  • Type changed from defect (bug) to idea

Replying to boonebgorges:

Who cares if our CI builds are slow? Obviously we don't want them to take days, but the difference between 20 minutes and 10 or 5 minutes is not significant enough that it should influence decisions about the software requirements.

You are correct when you hint that robots do not care that their time is wasted checking for unlikely conditions, and that it's better we task them to perform that job than waste our precious and expensive time. Whether or not to let a specific tool influence how a job is performed is up to engineers (see: us) to decide.

We allow IDE's to dictate filenames (#6051) so why not identify and cut out unrealistic integration tests?

According to updated WordPress stats the gap between 3.7 and 3.9 is just over 6% of installations. In a few months it will be 5%, which historically has been WordPress's guide for PHP versions, and also our loose guide for WordPress versions. We could bump to 3.7 now, and 3.9 later?

Last edited 5 years ago by johnjamesjacoby (previous) (diff)

#6 @boonebgorges
5 years ago

We allow IDE's to dictate filenames (#6051) so why not identify and cut out unrealistic integration tests?

The change to filenames is ultimately to save developer time and headache. If the only reason for changing WP requirements is to eliminate robot time and headache, I'm firmly against it.

As soon as supporting legacy versions of WP starts to require a discernible amount of developer effort, I think we should consider dropping support for those versions. But, realistically, how much time does any member of this team spend thinking about older versions of WP, when doing BP development? The introduction of date_query into Activity would have been one such case, but my guess is that it rarely happens.

If we insist on systematically bumping WP requirements, we should be far less aggressive. Maybe something like this: at the beginning of each major dev cycle, figure out which major WP version was current 12 months ago. In this case, it would be 3.8. We do a gut check against WP's stats page to make sure that usage number for versions < 3.8 is low enough to drop official support - we could use the 5% number that johnjamesjacoby suggests here. If we decide that it's droppable, then the first thing we do during the cycle is bump to that version in readme.txt. This gives developers the whole dev cycle to make any necessary changes.

#7 @boonebgorges
4 years ago

  • Milestone changed from 2.3 to 2.4

Let's talk about bumping supported WP version at the very beginning of the 2.4 cycle.

This ticket was mentioned in Slack in #buddypress by boone. View the logs.


4 years ago

#9 @boonebgorges
4 years ago

OK, let's revisit. According to https://wordpress.org/about/stats/, usage stats for old versions look like this (release dates in parentheses):

  • 3.6: 2.5% (2013-08-01)
  • 3.7: 1.7% (2013-10-13)
  • 3.8: 5.3% (2013-12-12)
  • 3.9: 8.0% (2014-04-16)
  • 4.0: 8.9% (2014-09-04)

The 5% rule suggests that we drop official support for 3.6 and 3.7.

As a cross-reference, 3.8.x was still the latest stable version as of early April 2014 (just before 3.9 came out). This is about 15 months ago. For 3.7.x, the "most recently stable" time is about 21 months. As I mentioned above, I think a good guideline for "most recently stable" is that we should maintain support for WordPress versions going back at least 12 months, which would suggest that we should definitely keep support for at least 3.8.x.

Based on the above, I'm going to suggest we bump the minimum official supported version to 3.8. If everyone else is OK with this, I suggest we do the following:

  1. Bump the minimum supported version in trunk
  2. Open a separate ticket where someone does a quick review of backward compatibility and progressive enhancements in BuddyPress that become obsolete when we no longer support 3.6 and 3.7, and make some recommendations for removal (or leaving stuff alone, as appropriate)
  3. Post about this on bpdevel
  4. Formalize these steps for future release cycles

Thoughts?

#10 @imath
4 years ago

Fine for me, even if i would have prefer 3.9 as before that plupload wasn't great for Avatar UI. But it's the case today for < 3.9 it's the old UI.
It's just that if we want to provide Attachments feature in the future i would have felt safer with 3.9 :)

#11 @johnjamesjacoby
4 years ago

Great write-up Boone. I agree with your assessment.

@imath: I have a hunch we can start dropping at least 1 old WordPress version with each new BuddyPress release, especially as more WordPress installations auto-update themselves. That means, we have until the end of the year to make it great? :)

#12 @imath
4 years ago

@johnjamesjacoby :)

#13 @boonebgorges
4 years ago

In 10031:

Bump minimum WP version to 3.8.

See #6258.

@netweb
4 years ago

#14 @netweb
4 years ago

In 6258.1.diff - Remove mysqli WordPress 3.7 wp_debug compatability tweak, originally added in r9238.

@netweb
4 years ago

#15 @netweb
4 years ago

6258.2.diff updates 6258.1.diff to add WordPress 4.2 to the Travis CI test matrix.

#16 @djpaul
4 years ago

In 10035:

Tests: remove Travis-Ci compat. for WP 3.7 + PHP 5.5+

This isn’t necessary now we’ve bumped the minimum supported WP version
to 3.8.

See #6258, props netweb

#17 @djpaul
4 years ago

In 10036:

Tests: add WP 4.2 to Travis-CI test matrix.

See #6258, props netweb

#18 @DJPaul
4 years ago

Keeping this open as we need to formalise these steps and write a post on bpdevel as per Boone's comment above

#19 @djpaul
4 years ago

In 10238:

Admin: remove WP 3.6. and 3.7-specific markup + images.

Our minimum supported WP version is now 3.8, so let’s tidy up outdated
CSS and images.

See #6258

#20 @boonebgorges
4 years ago

  • Resolution set to fixed
  • Status changed from new to closed

Keeping this open as we need to formalise these steps and write a post on bpdevel as per Boone's comment above

I did this a few months ago!

https://bpdevel.wordpress.com/2015/08/06/wp-version-compatibility-guidelines/
https://codex.buddypress.org/wordpress-version-compatibility/

If anyone has suggestions on how to improve/modify these documents, please feel free to post them (or edit the document directly). In the meantime, I think this ticket is resolved.

#21 @DJPaul
3 years ago

  • Component changed from Tools - Code Improvement to Core
Note: See TracTickets for help on using tickets.