Emulation General Wiki

Template:News

Revision as of 18:19, 30 August 2026 by Ilyagredasov (talk | contribs) (→August 2026)

Read this first

Click “Expand” on the right

  • If you're not sure what's updated, we've provided links at Getting involved for other aggregators.
  • The News section only fits 10 rows, if you add an 11th please move the oldest emulator update from the news section to the month section down below.
  • Keep the news section to unique pieces of software only (If simple64 2023-11-01 is in the news section and you want to add simple64 2023-11-02, please move simple64 2023-11-01 to the month section down below)
  • Link to news/changelog (use permalink if possible).
  • Date format is: YYYY-MM-DD
  • Use lowercase titles when necessary (some software titles don't start with a capital letter).
  • While adding a new release for a piece of software here, also don't forget to update its version number in its corresponding article.
    • If the piece of software you're updating this news section for has no its own separate article, then find it listed in another relevant article. For example, if you add a release of a PS1 emulator which has no its own dedicated article on this Wiki, then visit page «PlayStation emulators», and update version number there, if you want to add a new release for a frontend which has no its dedicated article, then visit page «Frontends» and update there, and so on.
      • If there's a version template for your software (shown in curly brackets) either on particular software's own dedicated page or in a more general list, then edit its code. For example, if you see {{hpsx64Ver}} while editing page's code (the template for emulator hpsx64), you open template's own page prefixed with "template:" (in this case it's template:hpsx64Ver) and edit the new release in. Thankfully, you don't have to type it manually, when you edit an entire page (not a particular section), its preview menu shows clickable template hyperlinks at the very bottom for templates used in that page, so you just have to preview your edits, scroll down to the very bottom and click a template link. Note: This particular PS1 emulator is long abandoned and only given here for the sake of providing an example for unfamiliar newcomers who wish to contribute to the Wiki, the version there is final, so don't edit it.
  • If a piece of software has more than 1 name, stick with 1 name for consistency to make it easier to search for past releases.
  • If a piece of software has its own dedicated article, don't forget to wikify, i.e. link to it by using doubled square brackets.
  • Nothing wrong if you miss something, emulators (and related software) are many, it's impossible to successfully monitor and keep track of every new release of every piece of software, so don't be surprised if the table isn't 100% complete. Remember it depends on YOU to keep it up-to-date. And you can still retroactively add missing versions for the preceding months or years if you want to bother.
  • Don't forget about differences in time zones. A quick thought experiment: an American author based in Washington DC releases a new version of his emulator on 10th September 6:00PM/18:00 (GMT -4:00). A Chinese author based in Beijing releases a new version of his emulator at precisely the same moment, but for him it's already 11th September 6:00AM/6:00 (GMT +8:00). Then an American emulator gets a bug hotfix 3 hours later. So even though a hotfix for an American author's emulator was in reality released 3 hours AFTER the Chinese emulator release, this hotfix date was still on 10th September (at 9:00PM/21:00) relative to the American author when it was on 11th September (at 9:00AM/9:00) relative to the Chinese author. This may create undesirable confusion. Unfortunately, there are no precise guidelines on how to deal with situations like this when you have to determine date. In some cases you may use your common sense, for example if a release is originally uploaded (not reposted) to a specific website as a primary source, and this site uses a specific time zone (not your local time), then it makes sense to use it to determine date. Or when a software piece uses release dates as version numbers, e.g. if GitHub-hosted emulator Q gets new version 2020-06-06, then it makes sense to use it (even if GitHub shows the release date as 7th June, not 6th) because apparently it was still 6th June in author's time zone; in other cases, you can potentially use different options at your discretion: author's local time zone, UTC, or your (wiki editor's) time zone, or time shown in a particular forum post (if the link to new emulator is posted in a forum message), or emulator's official website… you name it. Here's information which may be potentially helpful when you make a decision in case your software is hosted on a repository hosting and gets new releases there:
    • For GitHub, go to the repository, section "releases", find the release in question and its timestamp (e.g. "released 3 hours ago") near the release title, hover your mouse over this relative timestamp, and a tooltip will appear showing the exact date and time in UTC (used by GitHub). If you don't see the tooltip, click on the timestamp to see the exact time in the URL or page metadata. Additionally, you can append .atom to repository URL (e.g.: https://github.com/user/repo/releases.atom) to see the raw release feed with UTC timestamps (note that if it shows "updated" rather "published", it shows the timestap for the last git modification, not for the particular version release).
    • For Codeberg, the same applies, just use https://codeberg.org/user/repo/releases.atom
    • For GitLab, go to the repository, "releases" tab, hover over the relative timestamp (e.g., "3 days ago") to see the exact UTC time (also used by GitLab) in a tooltip. Alternatively, check the API response (e.g.: https://gitlab.com/api/v4/projects/[ID]/releases), which returns timestamps in ISO 8601 format (UTC).
    • For Mercurial, local time of the commit/release author (no universal standard) is used. Use «hg log» (no quotation marks) in the repository to see commit/release timestamps (time zone depends on the author’s system settings). Example command: «hg log --limit 1 --template "{date|isodate}\n"» and don't forget web interfaces (like Heptapod, Bitbucket) may convert timestamps.
    • For SourceForge, server time (historically PST/PDT, but often UTC now) is used. Go to the project → "Files" section → check the "Last Update" column. Hover over the date to see if a tooltip appears (some interfaces show UTC). For API/feed data (e.g., RSS), timestamps may be in UTC (e.g.: https://sourceforge.net/projects/[project]/rss).
    • For Bitbucket Cloud (which uses UTC for underlying storage like GitLab and GitHub but displays timestamps per your local time zone, based on account/browser settings), go to the repository → "Releases" tab (or "Tags" for lightweight releases). Hover over the relative timestamp (e.g.: "Released 2 days ago"). A tooltip will show the exact time in your local time zone. To see in UTC, either check the API response with this: «https://api.bitbucket.org/2.0/repositories/{username}/{repo}/refs/tags» and look for "date", or alternatively use browser dev tools (Inspect Network → API calls).
  • Sometimes code for new release may be posted on a repository with a delay after an actual release elsewhere (for example, emulator A got release 3.0 on Apple App Store like a week ago, but only today its GitHub repository finally updated, i.e. GitHub was hosting the outdated version 2.9 all this week). Or it may be omitted at all (for example, emulator B got a new release 1.6.0 on Google Play months ago but its GitHub repository still shows 1.5.0 as the latest release. Maybe 1.7.0 code will be posted on GitHub?). Or it may actually be released earlier (because the author made new release on GitLab first and spent a few days detailing its changelog before posting the news about this release on the emulator's official website). Once again, such cases are at your own discretion (although to use the earliest available date is advised). You may just update software's version elsewhere wherever mentioned on this week without updating this News template. Or you may post a link to this new release (on the aforesaid app stores, for example) outside its repository. A tip: try to be consistent if possible.
  • Regardless, try not to use not first-hand sources. Why post a link to a Reddit post or an X tweet instead of a news piece from software's official website, or a new release on its repository, or wherever the release was posted first?
  • Sometimes only a particular platform version is updated while untouched for the others. In such case don't forget to use tag <small></small> with relevant platform in brackets. For example, if emulator C is available for Windows, Linux, Android and Switch, but only a Linux version gets an update, add <small>(Linux)</small>.
  • You can also use tag <small></small> to point out a version numbering error. For example, emulator R uses release dates for number versions. On 20 August 2015, it got release but instead of expected version 2015-08-20 you see version 2016-08-20. Then you can just put the note between version and release date that: '''R''' – 2016-08-20 <small>(version numbering error)</small> '''2015-08-20'''. Same for cases where 2 versions are released in the same day but in wrong versioning order. For example, emulator Q which was previously at 30.0 gets new version on 20 May 2015 with version 30.2, then a few hours later a hotfix comes under version 30.1. In such cases, you can put 2 notes on both versions because the later release of the same software should be above the earlier one regardless of version number.
  • Otherwise it doesn't matter what order they're in if they're different softwares. If emulators J and W got their respective new releases on the same day and W's release came out a couple of hours later after J's one, it still doesn't matter if W is put above J or J is above W for as long as they're on the same day.
  • If some software B is a fork of another software A which closely follows the original (except having fork-specific features, of course) and both A and B were released on the same day, it makes sense to keep B's new version's entry on top, above that of A since A's new version came out earlier.
  • It makes sense to shorten the CI builds' artifacts' name for versions, for example "2.0-101" instead of "2.0-101-gaje7e8e8w38". Otherwise you end up with too long version numbering literally containing a particular commit. Suboptimal.
  • Put a later released versions into the month column instead of the news column even if the last entry has earlier release date whenever a single piece of software has several consequent releases because the News column only permits one unique software piece. For example, let's say today is 11 April. The last, 10th entry in the news column is release 12.3 emulator A from 3 April. Emulator B got 2 new releases, 1.5 on 9 April and and 1.6 on 10 April. What to do? Create a column for April (if it's not already created yet), and put B's 1.5 release there. Even though technically it's a newer release than As 12.3, it's still goes to April section instead of News section because the News columns shouldn't have 2 instances of a single program/application.

Aggregators

These websites aggregate emulator news and releases. Use them as discovery tools, not as primary sources. Whenever possible, link to the original GitHub (or other repository service the software in question uses) release page or official website instead.

Additionally, you can track releases manually with this free online tool supporting GitHub, GitLab, Codeberg, Bitbucket, Gitea and more.

News


August 2026

July 2026

June 2026

May 2026

April 2026

March 2026

February 2026

January 2026

Previous years

2020's
2010's
2000's
1990's
Retrieved from "https://emulation.gametechwiki.com/index.php?title=Template:News&oldid=149363"