The following discussion is closed. Please do not modify it.
There is no satisfying option for splitting of reuploads. I may revisit this in the future, but for now the status quo seems the tidiest method, or at least tidier than any splitting.
Nixinova T ⁄ C 06:35, 12 November 2025 (UTC) Currently, reuploads of versions (versions that use the same version number/name as a previous version) are documented only in the lead of their respective page. Examples: 1.6.2, 13w36b. Only versions with very different changes in each version / have lots of reuploads are given separate pages (e.g. 0.25, 0.0.15a).
This leads to an issue where non-trivial changelog information is placed to be only available in the lead. For instance, on 13w36b:
13w36b was reuploaded twice on September 6, 2013. The first time was to fix issues relating to the inventory key and the second was to roll back the control changes and to add a prompt which asks the player if they are sure they want to quit when they die.
This sentence includes information that could theoretically fill up a whole changelog page. The following would be what a page called "13w26b (reupload 2)" could contain:
== Additions ==
* Added a prompt to the [[death screen]] which asks the player if they are sure they want to quit when they die.
== Changes ==
; Controls
* Removed the control changes from [[13w26a (original)]].
Also, sometimes reuploads don't share the same version number: see 16w50a and 1.16.5-pre1. Are these still 'reuploads'? What is stopping them from being their own pages?
So, there are a couple questions to be had here:
- Should all reuploads be documented on separate pages? I.e., should every client JAR of Minecraft have its own page?
- What should the page title format be? "Version Name (reupload N)"? something else?
- Which page should be the "main" page? E.g., 1.6.2 has both pre-releases and reuploads titled simply "1.6.2". Should the initial or the final build be the "main"?
Nixinova T C 10:39, 29 May 2024 (UTC)
- Java Edition 1.4.6 is also an example of a page that would benefit from a pre-release / reupload / release split as there is enough content to fill separate pages for each. Nixinova T C 03:13, 19 June 2024 (UTC)
- Pre-merge content is available at the "(pre-release)" pages:
- Nixinova T C 03:19, 19 June 2024 (UTC)
- From a user perspective the "main" version/page name always needs to be the final combined changelog. Most users will have the final version as re-uploads usually happen quite fast, so looking at 13w36b and not getting the final changelog would be very confusing.
- However I also agree that reuploads should be documented better, ideally with extra pages. But only reupload pages would conflict with my first point, so for me these option come to mind:
- Put earlier uploads on their own page like
13w36b (before reupload 1).
- That would just be confusing for everyone.
- Have all uploaded versions as subpages like
13w36b/original, 13w36b/reupload 1 and 13w36b/reupload 2.
- This would allow for
13w36b to be a combined changelog for all uploads, while still documenting each individual upload on their own page.
- Instead of individual pages for reuploads, have them on the main page but document their changes in an extra section like
== First reupload ==.
- This would make the reupload content more clear, but also make earlier sections incomplete as they no longer describe all gameplay changes in the gameplay section.
- Of these option, #2 would be my personal favorite. A main page for the combined version with subpages for each individual upload. --👁 Image
MarkusRost (talk) 11:07, 29 May 2024 (UTC)
- > the "main" version/page name always needs to be the final upload
- Actually, I'd say the opposite. Someone going to "1.16" should get that full changelog, with "1.16 (reupload)" being a separate page. (Just an example - 1.16 reupload changed nothing so it wouldnt need a separate page.) That way the chronology is kept correct. Then for 1.6.2 we'd have a chronology of "1.6.2 (pre-release 1)", "1.6.2 (pre-release 2)", "1.6.2", "1.6.2 (reupload 1)" (e.g.) - the first full release of the version would get the page name and pre-releases and reuploads get parentheticals. Nixinova T C 11:44, 29 May 2024 (UTC)
- Sorry, that part was badly worded. I meant that the main page should include the complete changelog with all reuploads included. I have edited my initial comment to make that more clear. -- 👁 Image
MarkusRost (talk) 12:04, 29 May 2024 (UTC)
- With option 2, how would the duplication of information be dealt with? Nixinova T C 11:47, 29 May 2024 (UTC)
- I would just have the information duplicated, basically what we already do for releases with only a single dev version like Java Edition 1.20.1 and Java Edition 1.20.1 Release Candidate 1. (Why does 1.6.2 even include both the pre-release re-uploads and the release re-uploads? It seems like 1.6.2-pre was just the same as release candidates are now, so they should be two different pages.) I don't think the duplicated information would be an issue and using the subpage format would indicate clearly that 13w36b/original relates to or is a part of 13w36b, even Google should be able to understand paths relations like that in case there are any SEO concerns. -- 👁 Image
MarkusRost (talk) 12:52, 29 May 2024 (UTC)
- > they should be two different pages
- That's exactly what this forum post is for :D. And 1.6.2-pre did used to be a page, but it was merged to 1.6.2 due to the page title misleading everyone into thinking the version was actually titled differently. Nixinova T C 13:00, 29 May 2024 (UTC)
- See Special:Permalink/1383236 for 1.6.2-pre's last revision before being merged into 1.6.2 main. Nixinova T C 13:07, 29 May 2024 (UTC)
- I agree with Markus' opinion. However, the question left is how to refer to these reuploads. We can of course use "/original", "reupload #", though we may want to consider using the actual time of compilation (like
13w36b/1233, 13w36b/1256 and 13w36b/1307) or their "nickname" (e.g. 1.0.0/tominecon). TreeIsLife (talk) 17:16, 5 June 2024 (UTC)
- Timestamps are an alright idea but they'd be insonsistent lengths for e.g. 5minute reuploads and 2day reuploads. ‘/original’ etc are wordier but more usable imo. Nixinova T C 12:45, 29 June 2024 (UTC)
I've split the pages that have separable pre-release and release versions (1.6.2-pre, 1.7.4-pre) but the problem with reuploads specifically remains. Nixinova T C 12:40, 19 June 2024 (UTC)
Trying to revive this discussion, I strongly 👁 Image
Support using subpages as mentioned above. I would like to see them getting implemented soon, unless someone has any yet unvoiced concerns. -- 👁 Image
MarkusRost (talk) 00:59, 23 November 2024 (UTC)
- I'd still like some further discussion before this is just gone ahead and been done. I feel iffy on the presented suggestions as data duplication will be an issue, especially for pages where 99% of the content is from one instance and the reuploads have like 2 lines of changes each. Nixinova T C 09:02, 30 January 2025 (UTC)
- I think reuploads should have their own pages. Mudscape 👁 Image
talk 00:35, 9 February 2025 (UTC)
Let's try get something concrete out of this. I propose the rules for reuploads shall be:
- The concept of a 'reupload' only exists for versions of the game that are otherwise uniquely numbered. All unnumbered or corruptedly numbered versions (specifically: all Pre-Classic, Indev, and Infdev versions) shall have their own pages.
- The base version page shall be the first revision only of the version. No reupload content shall be present. All reuploads shall be clearly linked in the lede in their own paragraph.
- Each reupload gets a subpage of the original page ("/Reupload N").[note 1] Each page shall have a version nav with the infobox minor row navigating between reuploads and the infobox major row navigating between the base page's infobox minor row.
Nixinova T C 04:47, 10 February 2025 (UTC)
- ↑ I would use bracketed notation but this would be confusing for pages like Java Edition 1.6.2 (pre-release) - would it be '1.6.2 (pre-release) (reupload 2)'? That's strange.
- 👁 Image
Support GIM Dianliang233 (talk) 04:54, 10 February 2025 (UTC)
- Support. 2401:4900:A50F:7DC3:0:0:25A4:F144 09:43, 7 March 2025 (UTC)
- Wouldn't that mean that no page will have a complete changelog of all the reuploads combined anymore? Most users will only ever get the version as a update directly to the latest upload, so they mostly care about the combined changelog. The reuploads, while important info, are of less interest to most users following the changelog. -- 👁 Image
MarkusRost (talk) 15:30, 8 June 2025 (UTC)
- Hmm, I see your point. It would just make certain pages unwieldy. [1.16] vs [1.16/original] would be 99.999% identical, and would not resolve the problem of having to do <ref group="note">This bugfix occurred in the reupload of this version</ref> on the pages. Nixinova T C 04:04, 29 June 2025 (UTC)
- I guess the question comes down to what is a version in a reader's mind. 0.31 without qualification assumingly refers to all of them; if a user searches 1.16, do they expect to see the first release of v1.16 (the changelog version), or the version they'd get right now to play? I see both sides of this. Nixinova T C 06:18, 2 July 2025 (UTC)
