Now, it's almost guaranteed that the next update is 1.21. If not, we can change it already. Also, when I looked at the history of the template, I saw that when it was in version 1.9, versions were created for 1.10 and even 1.11, it was called "Future Update" for 1.10 and remained that way until 16w20a. Why not do it for 1.21 too? It's also free to change. Kırmacalı Talk Conts 18:02, 22 June 2023 (UTC)
- It will not be added until it is officially announced. Having it added now goes against rule #4 regarding speculation. BDJP (t|c) 18:58, 22 June 2023 (UTC)
- Okay... So, we will wait until Minecraft Live... Kırmacalı Talk Conts 20:10, 22 June 2023 (UTC)
Like BE, the icon for 1.11 is the effect hero of the village. For JE 1.14, could you do the same? 2001:4456:C54:D000:35CF:BC31:F03F:6C01 10:53, 30 July 2024 (UTC)
Should we split Infdev based on stages rather than by month? This would make more sense as the versions can be split more cleanly among these lines. For any confused about this, the 'stages' are defined quite well in Phases of Infdev. When it comes to icons, the current pyramid icon works well for phase 1, with the tree being used for stage 2, and the cage for stage 3. (Basically the current icons bar the arrow) Jubean (talk) 01:38, 20 August 2024 (UTC)
It's a bit confusing having an asterisk, which usually means "more info available below", to denote iterations. It would be better to use a symbol like + for this purpose instead. Compare
- 1.5** · 1.5.1
- 1.5++ · 1.5.1
Nixinova T C 10:22, 5 February 2025 (UTC)
- I find the indicator very confusing as there is no explanation anywhere on what it means. I would prefer a text solution instead, like adding "reuploaded" or "reuploaded twice" in brackets after the version (second list level). Ideally we would even have extra pages for the reuploads per Forum:Splitting reuploads which could each be linked in the mentioned way. -- 👁 Image
MarkusRost (talk) 00:40, 9 February 2025 (UTC)
- I would just remove the indicator completely. Mudscape 👁 Image
talk 00:51, 9 February 2025 (UTC)
- The ovbious choice would be to make an explanation about the asterisks. We can do this easily with
[[#navbox-version-reupload|*]] and {{anchor|#navbox-version-reupload}} for the note. – ItsPlantseed ⟨₰|₢⟩ 01:07, 9 February 2025 (UTC)
- Why do most people want to know how many times it has been reuploaded? I agree with Mudscape here. It always used to confuse me. (Sul4ur) 09:05, 9 February 2025 (UTC)
- Because each reupload is its own version, often having its own page. The navbox is for listing every version of the game. Nixinova T C 09:13, 9 February 2025 (UTC)
Grouping full release versions by groups of 5 years instead of multiples of 10
[edit source]Latest comment: 7 June 20252 comments2 people in discussion This old revision should be a good explanation for what I mean. Zenphia (talk) 10:33, 7 June 2025 (UTC)
- I'm not sure I see why we should change to this system? Everyone knows the versions much more by their numbering compared to their release year. - User-12316399 (talk) 12:48, 7 June 2025 (UTC)
My take on how to group the full release versions
[edit source]Latest comment: 8 June 20257 comments5 people in discussion The edits show that some editors thing groups of 10 major updates (1.0-1.9, 1.10-1.19, etc.) is an "arbitrary grouping". Well, if that's the case, then I'd say grouping them by every 5 years is also an "arbitrary grouping".
Anyway.
I'd say we can group it like this:
- 1.0-1.8
- 1.9-1.15 (from Combat Update)
- 1.16-1.19 (from Nether Update)
- 1.20 onwards (from introduction of drop system)
An alternate method would just to be keep the current system. I don't really see a reason to change it, but if we had to change it, I'd stick to what I just proposed.
If we had to go by years, I'd suggest the same grouping above, but changed to years, i.e.:
- 2011-2014
- 2015-2019
- 2020-2022
- 2023 onwards
However, development versions for any updates can cross years (e.g. 20w45a-21w20a for 1.17), so any usage of years for grouping versions would not be ideal in any circumstance.
Please suggest any other grouping methods if you have any. — 3A | T C 14:37, 7 June 2025 (UTC)
- I think this is a case of “If it ain’t broken, don’t fix it”. One could argue that choosing Combat and Nether Updates is more arbitrary than choosing minor version numbers (major being the initial 1) that are multiples of ten. — BabylonAS 14:44, 7 June 2025 (UTC)
- Honestly, I disagree with the idea that 3 groups for the full release versions is enough in the first place, especially considering that the 1.10-1.19 grouping covers versions spanning from May 2016 (16w20a, first 1.10 snapshot) to March 2023 (1.19.4, final minor update to 1.19)
- I feel like the following groupings make more sense:
- 1.0 through 1.7 (age of small updates)
- 1.8 through 1.12 (age of larger but less focused updates ignore 1.10)
- 1.13 through 1.18 (age of larger and more focused updates)
- 1.19 onward (age of experiments and drops) Sightnado (talk) 07:21, 8 June 2025 (UTC)
- 1.0 to 1.7: (8 major updates)
- 1.8 to 1.12: (5 major updates) (yes i know 1.10 is basically a drop, dw)
- 1.13 to 1.18: (6 major updates)
- 1.19 onwards: (3 major updates, 6 game drops (9 total))
- I don't think I'd consider 1.7 to be a "small update". Disregarding that, I'd say this works. Zenphia (talk) 17:57, 8 June 2025 (UTC)
- I don't like the idea of replacing an "arbitrary" system with an even more arbitrary system. Even intervals is better and more intuitive. 👁 Image
Oppose changing to anything suggested here. Nixinova T C 07:58, 8 June 2025 (UTC)
- My two cents on this:
“
The edits show that some editors thing groups of 10 major updates (1.0-1.9, 1.10-1.19, etc.) is an "arbitrary grouping". Well, if that's the case, then I'd say grouping them by every 5 years is also an "arbitrary grouping".
„
—
3A on grouping full release versions
- While I do concede that a perfect 5-year grouping is still arbitrary, the "powers of 10" system does not take into account the period of time between each update.
- 1.x: 2011 - 2016 (6 years)
- 1.1x: 2016 - 2022 (7 years)
- 1.2x: 2023 - ??? (2 years so far, and we aren't even at 1.22)
- I made the changes in response to the drop system's version numbering. Treating drops as separate from the major updates they're pegged to in all cases makes sense, not just the ones after Tricky Trials.
- Also, the wording of the text and the scare quotes around "arbitrary grouping" heavily imply that you do not believe that the 1.#x system is arbitrary.
“
I'd say we can group it like this; 1.0-1.8, 1.9-1.15 (from Combat Update), 1.16-1.19 (from Nether Update), 1.20 onwards (from introduction of drop system)
„
—
3A on his proposed system
- 1.0 to 1.8: 2011 - 2014 (4 years, 5 years if 2015 is counted due to that not having a major update)
- 1.9 to 1.15: 2016 - 2019 (4 years)
- 1.16 to 1.19: 2020 - 2022 (3 years)
- 1.20 onwards: 2023 - ??? (2 years so far)
- I strongly 👁 Image
Oppose this system as it is even more arbitrary (as it uses specific updates to use as waypoints for where to put everything else) and in my opinion is worse than just leaving it as is.
“
An alternate method would just to be keep the current system. I don't really see a reason to change it, but if we had to change it, I'd stick to what I just proposed.
„
- I hope I've made it clear why I 👁 Image
Oppose this too.
“
If we had to go by years, I'd suggest the same grouping above, but changed to years, i.e.; 2011-2014, 2015-2019, 2020-2022, 2023 onwards
„
- 2011 to 2014 (4 years)
- 2015 to 2019 (5 years, technically 4 since 2015 had no major updates)
- 2020 to 2022 (3 years)
- 2023 onwards (2 years so far)
- Same system, still 👁 Image
Oppose.
“
However, development versions for any updates can cross years (e.g. 20w45a-21w20a for 1.17), so any usage of years for grouping versions would not be ideal in any circumstance.
„
—
3A on development versions
- The years are for grouping major versions and game drops. I understand the potential confusion this could cause, but it's a very minor issue. Not everyone is looking for the year that a specific snapshot/pre-release/RC released.
“
Please suggest any other grouping methods if you have any.
„
- Like I've said before, a perfect 5-year grouping system is still arbitrary.
- Though if we had to group it by versions, we'd get:
- 1.0 to 1.8: 2011 - 2014 (4 years, technically 5 for reasons stated prior)
- 1.9 to 1.16: 2016 - 2020 (5 years)
- 1.17 to present: 2021 - 2025 (5 years)
- I suppose you could look at the number of major updates and game drops per group, too.
- 2011 - 2015: (9 major updates)
- 2016 - 2020: (8 major updates)
- 2021 - 2025: (5 major updates, 6 game drops (11 total))
- This simplified chart disregards the fact that more recent versions tended to have fewer minor releases. The Nether Update had six minor releases while Tricky Trials only had one. Certain minor releases (1.11.1, 1.16.2, and 1.19.3, for example) also straight up added some features, but they aren't considered game drops.
- So, on average, every grouping should be roughly the same size. I know the first group is mostly made up of quasi-drops, but it should still add up.
- Even intervals also just look nicer, but that's probably me being subjective. I hope we can eventually resolve this once and for all and that you now understand why I prefer the 5-year system, no matter how arbitrary it is. Zenphia (talk) 17:50, 8 June 2025 (UTC)
- > I made the changes in response to the drop system's version numbering. Treating drops as separate from the major updates they're pegged to in all cases makes sense, not just the ones after Tricky Trials.
- 👁 Image
Oppose. They're still point releases and should go under their parent. Nixinova T C 21:06, 8 June 2025 (UTC)
Wrong oak leaf sprite for Beta 1.1. it's using the updated version from 1.14+. Txt (talk) 03:19, 12 August 2025 (UTC)
- 👁 Image
Done 👁 Image
Ja17 07:34, 30 October 2025 (UTC)
Thoughts on the above? The Alpha 1.0.x especially line is very long currently, and this may make it easier to read. Nixinova T ⁄ C 03:18, 23 November 2025 (UTC)
- 👁 Image
Support those changes, it's a much friendlier design to readers than the previous one, and I didn't realize how "unreadable" it used to be back then. Rert 03:25, 23 November 2025 (UTC)
- 👁 Image
Support, though to be consistent with the rest of the navbox the Seecret updates should be their own full sections instead of subsections of the major updates. 👁 align=top
Sightnado ( talk / contribs ) 03:54, 23 November 2025 (UTC)
- I'd've done that but then I don't know where to put the Guide link. Nixinova T ⁄ C 03:55, 23 November 2025 (UTC)
- 👁 Image
Support per Rert. --MinecraftExp123(talk|contribs) 04:12, 23 November 2025 (UTC)
- 👁 Image
Support. –LauraFi - talk 04:18, 23 November 2025 (UTC)
- 👁 Image
Done Nixinova T ⁄ C 04:44, 23 November 2025 (UTC)
- The seecret updates can be promoted one level further if the problem of where to put the Guide link is resolved. Nixinova T ⁄ C 04:45, 23 November 2025 (UTC)
As most people familiar with Java Edition's version history should know, no version titled "Alpha v1.0.0" was actually released at any point. However, it is unclear which Infdev version Notch actually retroactively called Alpha v1.0.0: the June 29th version or the second June 30th version. This navbox claims the latter is Alpha v1.0.0, however the redirect for Alpha v1.0.0 leads to inf-20100629. What should our stance on this issue be?
I see two options:
1. Take the Alpha v1.0.1 announcement post literally and call the exact previous version (inf-20100630-1835) retroactively Alpha v1.0.0
2. Consider the shift to the Minecraft Launcher applet the beginning of Alpha (thus making inf-20100629 retroactively Alpha v1.0.0 and the two June 30th Infdev versions retroactively v1.0.0_01 and v1.0.0_02)
We'd also have to consider how to format the navbox in the latter case.
I personally 👁 Image
Support option 2, but I'm 👁 Image
Unsure how to format the navbox around that. 👁 align=top
Sightnado ( talk / contribs ) 03:52, 23 November 2025 (UTC)
- I say remove the Alpha 1.0.0 link from the navbox and apply neither of your options. Also the redir can be made into a disambig. 0129 and 0130-2 both have a valid claim to being the first Alpha ver and we shouldn't pick something arbitrarily. Nixinova T ⁄ C 03:55, 23 November 2025 (UTC)
- 👁 Image
Agree 👁 Image
amethyst_hhh👁 Image
03:57, 23 November 2025 (UTC)
- Pre-Release 1 → pre1
- Release Candidate 1 → rc1
Are we going to use "snap1" for when the inevitable 26.1 Snapshot 1 comes out?
Let's decide now before it happens. Nixinova T ⁄ C 00:04, 3 December 2025 (UTC)
- 👁 Image
Support "snap", clear meaning and already used somewhat commonly to refer to snapshots.--Capopanzo (talk | contribs) 00:07, 3 December 2025 (UTC)
- 👁 Image
Support, don't see any reason why not 👁 align=top
Sightnado ( talk / contribs ) 00:10, 3 December 2025 (UTC)
- 👁 Image
Support using "snap". –LauraFi - talk 00:12, 3 December 2025 (UTC)
- 👁 Image
Support per Capopanzo. –Redz(talk) 00:13, 3 December 2025 (UTC)
- I'd prefer using just numbers with bullets between them since there are a lot more snapshots than prereleases and release candidates and seeing "snap1 ∙ snap2 ∙ snap3 ... snap9 ∙ snap10 ∙ pre1 ..." would be pretty repetitive and a waste of space as opposed to "26.2 | 1 ∙ 2 ∙ 3 ∙ 4 ∙ 5 ∙ 6 ∙ 7 ∙ 8 ∙ 9 ∙ 10 ∙ pre1 ..." especially with some longer-period drops going up to 15 snapshots, and the names would all be unofficial unless the Launcher uses a specific shorthand name. 👁 Image
GameCatastrophe (talk) 00:15, 3 December 2025 (UTC)
- I've done some testing and in my opinion, using only numbers or having snapshots be level-2 bullets after the word "Snapshots" both work better visually. Here's my test 👁 Image
GameCatastrophe (talk) 00:54, 3 December 2025 (UTC)
- Single digit links won't be able to be clicked on mobile. Nixinova T ⁄ C 01:11, 3 December 2025 (UTC)
- Since they have the dot in between them, Im going to say they most likely can be, because I have no issues hitting this h 👁 Image
amethyst_hhh👁 Image
01:25, 3 December 2025 (UTC)
- Can confirm it is difficult to accurately hit single character links on mobile without zooming in 👁 align=top
Sightnado ( talk / contribs ) 01:26, 3 December 2025 (UTC)
- "pre1" and "rc1" are used in the launcher, so I think "snap1" should be used if and only if that's what's used in the launcher. --MinecraftExp123(talk|contribs) 02:26, 3 December 2025 (UTC)
- They say it'll be -snapshot-1. So a bit long. Nixinova T ⁄ C 03:55, 3 December 2025 (UTC)
- Then I 👁 Image
Oppose, because it would be unofficial and possibly not immediately clear. Maybe <abbr> tags can be used to clarify, though. --MinecraftExp123(talk|contribs) 04:05, 3 December 2025 (UTC)
- Why is officialness a concern? The navbox isn't trying to be, it's just trying to be as clear but concise. Nixinova T ⁄ C 04:29, 3 December 2025 (UTC)
- Fair enough; I'm just saying one may not immediately know what "snap" represents. --MinecraftExp123(talk|contribs) 04:38, 3 December 2025 (UTC)
- 👁 Image
Support using "snap", but 👁 Image
Oppose using just numbers with bullets. That might look better, but it makes harder clicking the links on mobile and it's less intuitive (someone that sees "1" will not necessarily think about a snapshot). A concern with both is that it would not be consistent with other version navboxes, mostly the Bedrock one, where we use the full name (the name of Bedrock previews is longer then the ones of these snapshots but we don't shorten them) D62 12:59, 3 December 2025 (UTC)
- 👁 Image
Support snap1. Consistent with other versions, using just the number is confusing because there is no indication of what version type it is and snap1 is already so short that saving more space is unnecessary, and I don't think it matters whether snap1 is official because we'd only be using it in a navbox. - Harri / Talk 👁 Image
14:34, 3 December 2025 (UTC)
- I would like to 👁 Image
note that the short form of pre-releases and release candidates will be changed to "pre-1" and "rc-1" instead of "pre1" and "rc1" according to Slicedlime’s table. I do believe that we don’t need to add the dash, though. — 3A | T C 07:18, 4 December 2025 (UTC)
- 👁 Image
Note: another thing I noticed while testing is that it's hard to distinguish snapshots from prereleases and release candidates at first glance. Like snap1 vs pre1 vs rc1. "ss1" maybe? 👁 Image
GameCatastrophe (talk) 14:09, 16 December 2025 (UTC)
- I edited "snap" to "ss" and it got reverted a while ago. I didn't see this thread, honestly I still think that's better, but I don't mind. — 3A | T C 14:12, 16 December 2025 (UTC)
- How about snapshot-1 (Launcher name) KirillVT (Chat) 👁 Image
👁 Image
👁 Image
14:59, 16 December 2025 (UTC)
- "snapshot-1" is too long for the infobox when compared to "pre1" or "rc1". There's a branch above that talks about just that. — 3A | T C 15:01, 16 December 2025 (UTC)
- s1 and ss1 both seem to solve the problems. Perhaps s1 is a little more clear as to what it means but we should understand that in-context it will be a lot more clear that what it looks like on the talk page, so there's no need to stretch for clarity. Plus, you can always use tier-2 lists after "snapshots" like "Snapshots (s1 ∙ s2 ∙ s3)" 👁 Image
GameCatastrophe (talk) 15:06, 16 December 2025 (UTC)
- 👁 Image
Support KirillVT (Chat) 👁 Image
👁 Image
👁 Image
15:07, 16 December 2025 (UTC)
- I think that "s" is too short for the infobox as it may cause problems on mobile devices, and a single "s" may not be enough to convey the meaning of "snapshot". As mentioned above, I believe that "ss" works best as the abbreviation. — 3A | T C 15:09, 16 December 2025 (UTC)
- 👁 Image
Support ss1, added. KirillVT (Chat) 👁 Image
👁 Image
👁 Image
15:11, 16 December 2025 (UTC)
- Not it works. Stop changing the version number until the discussion ends. RedX (talk) 15:18, 16 December 2025 (UTC)
- It will make more sense in-context than on a gray void, and it's "s1" not just "s" and as stated above single-digit links aren't always difficult to press on mobile so double-digit links probably wouldn't have more issues than triple-digit links 👁 Image
GameCatastrophe (talk) 15:13, 16 December 2025 (UTC)
- As I mentioned on Discord, I think out of all acronyms it's best to avoid "ss". Besite its meaning, I think "snap" is more understandable than "ss". I'm not sure what's wrong with "snap". - Zamburger (talk) 19:28, 16 December 2025 (UTC)
- The problem, if you'll read the previous replies, is that it looks too similar to "preX" 👁 Image
GameCatastrophe (talk) 20:47, 16 December 2025 (UTC)
- Just read it a little closer?
- 26.1 | snap1 snap1 snap3 snap4 snap5 snap snap7 pre1 pre2 pre3 rc1 rc2
- This doesn't seem hard to parse. Nixinova T ⁄ C 21:04, 16 December 2025 (UTC)
- Oppose "s" or "ss", those aren't good abbreviations. Nixinova T ⁄ C 19:29, 16 December 2025 (UTC)
Just like with snapshots, change Combat Test to ct. Example: ct6 KirillVT (Chat) 👁 Image
👁 Image
👁 Image
15:12, 16 December 2025 (UTC)
- They're in a different section, not much need for differentiating 👁 Image
GameCatastrophe (talk) 15:22, 16 December 2025 (UTC)
- Oppose, we don't need to abbreviate those. Nixinova T ⁄ C 19:29, 16 December 2025 (UTC)
- Use "👁 Image
Oppose" instead of "oppose" KirillVT (Chat) 👁 Image
👁 Image
👁 Image
20:12, 16 December 2025 (UTC)
- This is completely irrelevant to the discussion. RedX (talk) 20:23, 16 December 2025 (UTC)
Why are some developer builds in italics and others aren't? Shouldn't they be either all or none? D62 11:39, 21 December 2025 (UTC)
- They should all be italicised yes. Nixinova T ⁄ C 11:42, 21 December 2025 (UTC)
Combat tests 7x and 8x are (most likely) on wrong depth of list (it probably should be "• ct6 • ct7 (ct7a • ct7b) • ct8 (ct8a •" etc, or something like that). If it is as it supposed to be, why? It doesn't look logical (at least on a phone). ~2026-GraniteMinecraftBedrock3963 (talk) 23:20, 24 February 2026 (UTC)
- The list is presented correctly. 7 and 7b are dev versions of 7c, and 8 is a dev version of 8b. BDJP (t|c) 23:23, 24 February 2026 (UTC)
Flatten out In(f)dev labels
[edit source]Latest comment: 4 April4 comments3 people in discussion I think the In/f/dev parts of the navbox are a bit messy looking, with a lot of distracting punctuation.
So I ask: which of these two looks better?
A (status quo)
or B (new):
Nixinova T ⁄ C 04:57, 30 March 2026 (UTC)
- I prefer B, it's an improvement. –LauraFi - talk 07:32, 30 March 2026 (UTC)
- I'm not familiar with Inf?dev versions, but B seems cleaner as grouping by time doesn't seem to make a lot of sense for the versions themselves. ‑‑MinecraftExp123(talk|contribs) 08:03, 30 March 2026 (UTC)
- 👁 Image
Done Nixinova T ⁄ C 07:24, 4 April 2026 (UTC)
