Move release history to api.wordpress.org

[ramiy]

Currently, the about.php page has a release history for minor versions. The problem is that this information is hardcoded in the about page.

Each time a new minor version released, the about page is updated with new strings linking to the new version codex page - for example [36455]. For each security version, it's done for all previous versions (3.7-4.4). See the attached screenshots.

I would like to move the minor version release history to ​api.wordpress.org, this way all the information will be pulled automatically for each version, and will be available for external services - not just for wordpress core. Again, if it won't be hardcoded, this information will be available to external services.

I can write the code for the core, and create the API in dotorg (separate ticket will be opened in meta trac).

---

Proposed API endpoint: ​https://api.wordpress.org/core/minor-versions/1.0/?version={wp_version}

The API will return a list of minor versions. For each release we will provide information like: version number, release date, release type (maintenance, security or both), number of bugs fixed and a codex link to the release notes.

Basic API response (can be changed):

{
	"data" : {
		"version" : "4.4"
	},
	"minor-versions" : [
		{
			"number" : "4.4.1",
			"date"   : "2016-01-06 00:00:00",
			"type"   : "security",
			"bugs"   : "16",
			"url"    : "https://codex.wordpress.org/Version_4.4.1"
		},
		{
			"number" : "4.4.2",
			"date"   : "2016-02-02 00:00:00",
			"type"   : "security",
			"bugs"   : "52",
			"url"    : "https://codex.wordpress.org/Version_4.4.2"
		},
	]
}

[dd32]

Each time a new minor version released, the about page is updated with new strings linking to the new version codex page - for example [36455]. For each security version, it's done for all previous versions (3.7-4.4). See the attached screenshots.

These strings are not new "added" strings, they're existing strings for the express purpose of being used in that exact area. The only new information which we include are the numbers which are added in.

The possible strings exist at the bottom of the about.php file: https://core.trac.wordpress.org/browser/trunk/src/wp-admin/about.php#L204

Moving any of this information to the API gives zero benefit.

[ramiy]

Actually, I am not talking about translation strings, we are not going to add/delete translation strings.

Check out those commits: [36456] (wp4.3.3), [36457] (wp4.2.7), [36458] (wp4.1.10), [36459] (wp4.0.10), [36460] (wp3.9.11), [36461] (wp3.8.13), [36462] (wp3.7.13).

In each new minor version, you need to change the about.php to update the number of minor-versions and add the last minor-version changes. This can be done automatically using foreach loop - the data will come from api.wordpress.org.

We are already doing this in credits page, ​we pull the data from api.wordpress.org, and create the view using foreach loop. Let's apply the same principle for the "minor release history".

[ocean90]

We have to do the commits anyway, and there is no real difference in committing the change to core or to the API. Because of that I prefer core because more people can make/commit such a change.

[SergeyBiryukov]

Replying to ramiy:

I would like to move the minor version release history to ​api.wordpress.org, this way all the information will be pulled automatically for each version, and will be available for external services - not just for wordpress core. Again, if it won't be hardcoded, this information will be available to external services.

Do you have a particular use case for this information?

[ramiy]

@ocean90, when this information is committed into core, it's not available for external sites.

For example, we can use this data in ​developer.wordpress.org.

[ramiy]

Replying to SergeyBiryukov:

Do you have a particular use case for this information?

Yes I do.

It was my personal weekend project, and the site is still in development, but you can visit ​http://displaywp.com/version/44/