The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
A major WordPress version is dictated by the first two sequences. For example, 3.5 is a major releasemajor releaseA release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.. So is 3.6, 3.7, all the way up to 4.0. Version 4.0 is no different than 3.9 and 4.1. There isn’t a “WordPress 3” or “WordPress 4” – we’re weird like that for historical reasons.
Major releases add new user features and developer APIs. Though typically a “major” version means you can break backward compatibility (and indeed, it normally means that you have), WordPress strives to never break backward compatibility. It’s one of our most important philosophies, and makes updates much easier on users and developers alike.
A minor WordPress version is dictated by the third sequence. Version 3.9.1 is a minor releaseMinor ReleaseA set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality.. So is 3.8.2. A minor release is intended for bugfixes and enhancements that do not add new deployedDeployLaunching code from a local development environment to the production web server, so that it's available to visitors. files and are at the discretion of the release leadRelease LeadThe community member ultimately responsible for the Release. with suggestions/input from component maintainers and committers.
Since new versions of WordPress are released so frequently – we aim for 4-5 months for a major release, and minor releases happen as needed – we only have a need for major and minor releases. We don’t have bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.-fix or “patchpatchA special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing.” releases you normally see with an X.Y.Z-style version number. Rather, we have an X.X.Y version number.
While it’s a bit confusing, our commitments to backward compatibility and fast release cycles make it very easy for users to be able to update without worrying. (Which is great, considering the days of the version number are numbered…)