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 our bug tracker.
Phase 1: Planning and securing team leads. This is done in the #core channel. The release leadRelease LeadThe community member ultimately responsible for the Release. discusses features for the next release of WordPress. WordPress contributors get involved with that discussion. The release lead will identify focus leads for each of the features.
Phase 2: Development work begins. Focus leads assemble teams and work on their assigned features. Regular chats are scheduled to ensure the development keeps moving forward.
Phase 3:BetaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.. Betas are released and beta-testers are asked to start reporting bugs. No more commits for new enhancements or feature requests are allowed for the rest of the release.
Phase 4: Release Candidaterelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).. There is a string freeze from this point on. Work is targeted on regressions and blockers only.
Phase 5: Launch. WordPress version is launched and made available in the WordPress Adminadmin(and super admin) for updates.
The launch is often followed soon after by 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. (also known as a point 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.) as bugs are reported and squashed. 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 lead with suggestions/input from component maintainers and committers.