WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#35971 closed enhancement (wontfix)

Move release history to api.wordpress.org

Reported by: ramiy Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Help/About Keywords: has-screenshots
Focuses: administration Cc:

Description (last modified by SergeyBiryukov)

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"
		},
	]
}

Attachments (2)

minor-version-4.4.png (166.9 KB) - added by ramiy 5 years ago.
minor-version-3.7.png (365.9 KB) - added by ramiy 5 years ago.

Download all attachments as: .zip

Change History (11)

#1 @ramiy
5 years ago

  • Keywords has-screenshots dev-feedback added

#2 @SergeyBiryukov
5 years ago

  • Description modified (diff)

#3 @SergeyBiryukov
5 years ago

  • Component changed from Administration to Help/About

#4 @dd32
5 years ago

  • Keywords close added; dev-feedback removed

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.

#5 @ramiy
5 years ago

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".

#6 @ocean90
5 years ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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.

#7 in reply to: ↑ description ; follow-up: @SergeyBiryukov
5 years ago

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?

#8 @ramiy
5 years ago

@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.

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

#9 in reply to: ↑ 7 @ramiy
5 years ago

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/

Note: See TracTickets for help on using tickets.