Changelog proposal

Recently I mentioned that we need to have a standard changelog format. Not only does this benefit us as reviewers but it also benefits the users because it lets them know what has changed. This is important if a theme update has a security fix or it makes drastic changes. Users can then decide if the update is worth it for them or not. Plugins provide them and I feel themes should as well. We have tried to recommend this in the past but it hasn’t stuck.

There are currently two tickets that should be watched. The first one is the metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. ticket. It is a little outdated because the tabbed theme browser no longer exists but can be easily amended to include a link to the changelog file.

Meta ticket:

The second ticket being the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. one. This is what the user will see when they are on the update screen on the Appearance screen.

Core ticket:

If we want to make this happen, ideally we should be following the core development release cycle. As you can see 4.3 is scheduled release around August and 4.4 in December.

Core Development Roadmap:
4.3 – August
4.4 – December

What does this mean? It means in order for this to happen we have to require a changelog or a section in the readme file with a changelog and we have to set a timeframe. We would also need to have a standardized format that theme authors can easily and quickly adhere to. What I’d like to propose is requiring a dedicated changelog file that follows the format of:

== changelog ==
= 0.3.1 =
* Added Dutch, French translations
* Fixed nav menu not displaying in mobile devices

= 0.3.0 =
* Fixed PHP error in some hosting environments

Let’s discuss!