Template talk:History/Archive 1

Suggestions
I think the version numbers should link to the respective section in the version history page so people can see the full changelog as well. Instead of having a separate section for development versions, maybe they should just be integrated into the release cycle type. For example, the weekly snapshot version changes can be integrated into the full release section, and beta pre-release changes into Beta section, so this way the chronological order is maintained. -  05:07, 9 June 2012 (UTC)


 * I'm working on the version number links. As for the pre-release thing, I think it makes the most sense if changes are sorted by officially released versions (not prereleases). This means that a feature introduced in the Beta 1.8 prerelease is listed under Beta 1.8, and a feature introduced in the Beta 1.9 prerelease is listed under Minecraft 1.0.0 (since Beta 1.9 eventually became Minecraft 1.0.0). If there is no official release yet (as is currently the case with the 1.3 snapshots), it gets listed as an upcoming feature, similar to how other templates and pages handle the snapshots (just look at the list of blocks for an example). — 05:15, 9 June 2012 (UTC)


 * Then this formatting style is basically the same as the one used in the version history article. If we format it like this, then how will we order the update notes during each development release (links, videos, images, etc.)? I think the purpose of a history section for each topic is to group the changes regarding the article topic into an readable section and to log the events/images/etc. that cannot be added to full version change list. Instead of grouping the development versions into the upcoming section, how about adding them to the full release section (for snapshots) in chronological order? This way it maintains the first (development) version in which specific features were implemented/changed. Pre-release changes can be added into the Beta section. -  05:41, 9 June 2012 (UTC)


 * I think you misunderstand me. I agree with you on adding Beta prerelease changes to the actual release they were made for. In fact, that's what I've done in the pages I've already updated. In order to be consistent with the rest of the wiki, however, pre-release changes that have not yet been released yet should be marked as such (planned or upcoming). In doing this, the order stays perfectly chronological. — 05:54, 9 June 2012 (UTC)


 * Ok, so after the official version is released, the development version changes will be moved to the official release section. I think it's best if the development version number is maintained for each change after they are moved to the official release section. -  06:02, 9 June 2012 (UTC)


 * I looked at the conversions you made, and you were leaving out some of the development version details. Pre-releases should be placed between Beta and Official release since those pre-releases were part of the Beta cycle. This format may actually take more effort to maintain if we have to move the upcoming section changes into the official release section each time the official version is released. Why don't we just list the changes, along with the snapshot version, directly under the official section since these snapshots are part of the official release cycle. This way there's no need to move them again. -  06:27, 9 June 2012 (UTC)


 * Please tell me what exactly I have “left out”. The additional effort is, as has been proven repeatedly, no problem for the large community. The snapshots are not official releases, they are only a way to test new features and find bugs. Also, please refrain from editing the articles based on your suggestion until a consensus has been reached on the matter, to prevent edit wars. — 07:52, 9 June 2012 (UTC)
 * What Orthotope said below was what I was trying to tell you about. -  01:55, 10 June 2012 (UTC)
 * I'm a bit concerned about the loss of detail caused by merging snapshot notes into the release version. Take emerald ore, for example. If we just have '1.3: Emerald ore added', we lose information about the changes in its generation in the last few snapshots. On the other hand, it is nice to have the release version, so you don't have to check to see which one a snapshot became part of. One solution might be to list both the snapshot and the full release it became part of. For example:


 * {| class="wikitable"

! colspan="3" | Official release ! 1.2.5 ! rowspan="2" | 1.3
 * || release stuff
 * 12w19a || snapshot stuff
 * 12w23b || more snapshot stuff
 * }
 * }


 * The code for that would be a bit gnarly, so another option is to mention the snapshot version in the history entry. -- 07:54, 9 June 2012 (UTC)


 * We could have two versions of the table — one with the releases only and one with all the details from development versions and leaked info — and let readers switch between them at the click of a button (similarly to how the table of contents can be collapsed or expanded completely). This might require help from an admin since it uses JavaScript and I'm not sure how MediaWiki and JavaScript work together, but it definitely can be done. It would be the best of both worlds. And don't worry about gnarly code, the template syntax for this can still be kept pretty clean. — 08:09, 9 June 2012 (UTC)


 * That would work, if it's possible; it's well beyond my abilities. Ultradude25 seems to be the resident wikicode and JS/CSS expert, so I'd like to see what he thinks. -- 08:26, 9 June 2012 (UTC)


 * That could probably be done if mw-collapsible would work, but I don't think Curse has fixed it yet. – (&#124;) at 09:20, 9 June 2012 (UTC)


 * I don't even see mw-collapsible on . Or is that the problem? Anyway, we would need a way to provide a button that hides one part of the code (the release overview) and shows another (the snapshot-by-snapshot details). Does mw-collapsible do that? — 09:34, 9 June 2012 (UTC)


 * is a built-in part of mediawiki. I did actually manage to fix it a while back, but that was by removing a part of its code... so I assume it must break somewhere else now, but at least it seemed to work on basic usage.


 * I've made some changes to the template so there is only one parameter name, and added the verlink template to it. – (&#124;) at 11:07, 9 June 2012 (UTC)


 * Although mw-collapsible does not have all the features we would need for this, I have tried to make a table where changed made in development versions should be hidden by default. However, they are not. mw-collapsible does not work as described on the MediaWiki page. — 12:55, 9 June 2012 (UTC)


 * Exactly... it's broken. – (&#124;) at 13:19, 9 June 2012 (UTC)


 * On an unrelated note, is there any particular reason for having the template generate raw HTML rather than wikicode? -- 07:54, 9 June 2012 (UTC)


 * I had problems with the wikicode table in the parser functions, so I changed it to a HTML table. Feel free to fix that if you know how. — 08:09, 9 June 2012 (UTC)


 * Because templates and wikicode tables won't work without escaping them, which is much uglier than just doing the tables in HTML. – (&#124;) at 09:20, 9 June 2012 (UTC)


 * I did try to escape them, but it didn't really work the way I thought it would. And yes, it's ugly. I got confused way too quickly. — 09:34, 9 June 2012 (UTC)

For my previous comment: The other snapshot release dates that are already released officially should retain their original version, and not be merged into the official version. For example, the Beta pre-releases such as 1.9preX should be in the Beta section, not the 1.0 release section, because the changes were added in the Beta release cycle, not the official release. The snapshot versions that are already released in 1.2.5 should be in the official release section with the development version in which the change was added, and not be merged into the 1.2.5 label that doesn't accurately show the exact version change. -  19:05, 9 June 2012 (UTC)

For example, has a situation in which a feature was changed in 1.9pre4, but was removed in 1.0. If they are all merged into the official release version, the player loses context for the next change. The development version will NOT be merged or relabeled. -  05:04, 10 June 2012 (UTC)

Maybe there can be a field that allows dates to be added, or any custom note, instead of linking to a version history page. Content that do not have specific versions (e.g., image previews) can be left above the template, or it can be added into the template above the version changes. -  22:14, 9 June 2012 (UTC)


 * The new version of the template will take care of all that. — 05:38, 10 June 2012 (UTC)

Linking to version history
Well, now we can't post a non-update history entry. Can someone re-add the blank entry parameter to allow for that? -- 01:09, 1 September 2012 (UTC)
 * Oh nvm, "unknown" takes care of that. -- 01:10, 1 September 2012 (UTC)

Link parameter not working with page links
Thinking about the hack Hower64 did to allow page links instead of external links for the |link= arg, would the following fix that? I am honestly confused about complex wiki markup code, so I don't want to edit this in and cause an issue.

Replace the following line with this
 * [ ] }}
 * [ ]
 * }}

This way, if we need to have the date in History tables link to another page, we just use the |page= arg. 03:17, 28 December 2012 (UTC)


 * This wouldn't what you want it to do, sorry. — 03:48, 28 December 2012 (UTC)

Xbox 360 upcoming
So I added Xbox 360 upcoming features to the template, however when I then add a version under it, it still links to the version history instead of the upcoming features page, how do i fix this? 21:34, 13 January 2013 (UTC)


 * Since this is Template:History, you wouldn't have xbox upcoming features on here at all. The only reason there is an upcoming section for PC is because of the weekly snapshots, as while the feature is upcoming for an official version, it has actually been released as a snapshot and is documented as part of history. – ᐸ  01:18, 14 January 2013 (UTC)


 * Good point. I guess I shall revert my addition. However I'd like to see something where upcoming xbox features can be told about. 16:16, 14 January 2013 (UTC)

Dev is not Official. Fix it!
Developmental history is not Official Release history!

They should NOT be linked the way they do. For the majority of players, people don't really care about the beta release, and we really just want to see what has been released based on specific real version numbers. The current system causes all kinds of confusion where the end user has to look up the current release's corresponding development version number and backtrack it from there. This is broken and unintuitive.

I think one of the big questions here is whether all the snapshot features actually get released into the official SVN or if they are put into snapshots experimentally. I went searching between the two lists for a while and found an extremely hard time tracking which features were fixed and which official version it went out to.

As an end user, I don't know what development version my client recently got... it is not shared with client info without significant research. Giving the developmental release of a feature being changed instead of the official release breaks a lot of things, for example: searching for specific things on youtube where people cite the regular version number and not the dev designation. You can't match the two up.

Development versions are nice for people working with development, but lets fix this and stop labeling development versions as official versions please? 17:50, 5 February 2013 (UTC)

Now that I'm thinking about this a bit, what we could do in entries is move developmental release numbers into a new header in the History template called Developmental Releases. Then, add the appropriate stable information in the Official release section of the template using the wording from Mojang. This would require lots of work editing the pages, but it really needs to be fixed. 00:50, 6 February 2013 (UTC)


 * I have made a new version of the template to demo the ability to toggle displaying the developmental versions under the official version.
 * Currently, an official version's history can be split up by putting the developmental version number in a pre tag (put a space at the start of the line)
 * Then clicking the show details button will show those versions next to the official version number.
 * Changes that only make sense to show in the details view (such as a bug that was introduced in one snapshot, and fixed in the next) can be hidden by using an ordered list instead of an unordered list. The change will then only be shown (as an unordered list) in the details view.


 * This is just a demo of the functionality, we can decide what needs to be changed from here before we actually put this into use. – ᐸ  03:05, 9 February 2013 (UTC)

Raspberry Pi Edition
A few bits of edits are needed for the Raspberry Pi edition as I can't put some stuff into the Flowers page history as I am new to the wiki and as far as I can see there isn't s Raspberry Pi bit in the template code. I looked at the code and thought I wouldn't risk editing it 20:38, 19 February 2013 (UTC)


 * Added. -- 05:49, 20 February 2013 (UTC)

Snapshots sorted by official release version
Hey,

it would be great, if the template of the history would be changed to the one,

Orthotope suggested on 07:54, 9 June 2012 (UTC)

It is hard to know, at which point a feature has been implemented in an official release (1.2, 1.3, 1.4.5 and so on) if you only see the snapshot numbers. As an example I would tell you to go to the page of the map item.

Thanks!

11:31, 24 February 2013 (UTC) McMicGera

Add Development history type
It seems as if the addition of a Development Version type would alleviate the confusion between development versions and official versions. Currently, the template pushes development versions onto the official releases category, which is incorrect. 19:19, 10 April 2013 (UTC)


 * Snapshots are considered 'released' once their content has been included in an official update. Putting all development versions in their own section would break the chronological ordering of entries. -- 19:33, 10 April 2013 (UTC)


 * If the snapshot doesn't have a release version yet, put the entry under a which will put it under "Upcoming". If a snapshot entry is listed under "Official Release", it means whatever change that snapshot has is now included in a main release. There shouldn't be any confusion with the snapshot numbers. The history template does have the ability to list the release versions to the left of the snapshot versions in order to differentiate between the snapshot releases. An example of this is on    20:28, 10 April 2013 (UTC)


 * Why can't we just simply start using as that was what it was designed for? Btw the last edits for the History2 template was 10 February 2013, meaning that it's been two months since that was set up. –  ᐸ    05:43, 13 April 2013 (UTC)


 * That isn't really usable. It was a test concept on a way to handle the snapshot versions, but it doesn't really work very well. While the current way to do it isn't great, it will do until we get lua. – ᐸ  14:04, 13 April 2013 (UTC)

Change upcoming to development
"Upcoming history" has always been weird, it would be better to call it "development" or something like that. – ᐸ  09:45, 15 June 2013 (UTC)

Release versions in Upcoming section?
There's been a bit of an edit war between me and regarding whether or not to include the release version number in the Upcoming part of the History sections. This part of the documentation clearly refers to the Official release part. Also, Matt argues that How would this be useful when the version does not even exist? — 04:44, 28 September 2013 (UTC)


 * It is useful as it shows what version to expect these features in when it is released. Most history sections already have a version/snapshot pair, so it doesn't take up any extra room to have the information there, and even in cases where there isn't any already, it barely takes up any space. What benefit is there to not have this information? – ᐸ  ⎜ 05:49, 28 September 2013 (UTC)


 * It is misleading: 1.7 is not a released version of Minecraft yet, while the “1.7” on makes it look like it is. We have enough problems with people confusing the snapshots for releases already. It also currently links to a hanging anchor on, which illustrates my point: it's just not there. Besides, as little space as it may take up, it still adds clutter. — 06:12, 28 September 2013 (UTC)


 * Well it's under the heading "upcoming" so I don't see how anyone could be confused by that. However, the hanging anchor seals the deal for me. It's gotta go. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 08:04, 28 September 2013 (UTC)


 * I have edited the template docs to make this more clear. — 13:40, 21 October 2013 (UTC)

Upcoming Pocket Edition
It would be good to see a Upcoming for Pocket Edition category, so any information about the upcoming 0.9.0 update can be put there. Currently, some people are putting information from 0.9.0 into history tables already, however 0.9.0 isn't released yet. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>  09:36, 2 March 2014 (UTC)


 * This is the history template. The only reason we have the (poorly named) upcoming section at all is for development version releases which haven't been put in official releases yet. If this 0.9 update has a released development version, then it can go in Pocket Edition's existing upcoming section, otherwise it doesn't belong in history at all. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 09:44, 2 March 2014 (UTC)


 * Ok, thanks for the reply. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   11:43, 2 March 2014 (UTC)

Color coding the editions
The different editions of the game (PC, Pi, Pocket, Xbox) should be more easily distinguishable in the template. I propose color coding the table cell background for the different editions. The different development cycles within one edition would still have the same color (for example, Classic and Upcoming would be the same color as Release, and Pocket Alpha would be the same as Pocket Beta). Here's the colors I've come up with:

— 13:49, 5 March 2014 (UTC)


 * It could work for the header of each edition, but it might be too much to colour the whole table, probably need to make a mockup. On that topic, something I was considering was having each edition in a separate table <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 14:24, 5 March 2014 (UTC)


 * of the different variants. I think the “everything colored, same table” one looks best. — 02:16, 18 March 2014 (UTC)


 * If we were to have separate tables, they would be set 100% width. Full colour looks alright, but I'm still leaning towards just the headers, personally. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 03:16, 18 March 2014 (UTC)


 * I also prefer headers only, the rest seems a bit busy/too colourful. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   07:00, 18 March 2014 (UTC)

Renaming Xbox Edition to Console Edition
Now that there is a Playstation version (basically an exact replica of the Xbox version), could someone edit the template so the Xbox 360 Edition header gets changed to Console Edition? <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>  07:05, 18 March 2014 (UTC)


 * According to the article, they are not the same. Besides, the PlayStation version came out much later, no? So I think there should be separate sections for the two. (Correct me if I'm wrong, I don't play console Minecraft.) — 03:46, 21 May 2014 (UTC)

Changing parameter functions
Would there be a problem with changing to set the link, rather than simply adjust the type of link for ? I'd assume based on usage that it is rarely used thus far, and any current usage could easily be adjusted.

An example of the code required can be seen

-- ( 15:15, 3 September 2014 (UTC)


 * So I went ahead and added it, after remembering -- ( 18:52, 6 September 2014 (UTC)

Removing rowspan parameter
, (plus anyone else concerned)

I have found a way to eliminate the need for the rowspan paramater using, as this template could count the number of rows after it (see use ). My main question is can you think of any problems with using that, such as memory or variable limit. It would require a variable to be generated for each use of the a version with a snapshot (automatically of course), plus using a function claiming to be experimental. -- ( 04:35, 7 September 2014 (UTC)


 * -- ( 03:49, 8 September 2014 (UTC)


 * I'd love to get rid of that parameter, give it a try. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 05:19, 8 September 2014 (UTC)


 * It worked! rowspan is now automatic. Majr@undefined Would you mind removing the outdated rowspan parameters using you bot? -- ( 14:17, 8 September 2014 (UTC)


 * I'd rather leave it for a bit so we can easily revert if there is a problem. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 00:45, 9 September 2014 (UTC)


 * The only problems I found so far were caused by incorrect usage of the template. I had to remove support for a few cases to make the new system fully work, so I adjusted the incorrect usages. -- ( 00:52, 9 September 2014 (UTC)


 * You could've just removed the rowspan parameter from the template. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 00:53, 9 September 2014 (UTC)


 * was removed completely, the problem was attempting to pass a blank content with, rather then using the value "unknown". The other problem was attempting to use with no , in which case adding support would be more trouble than it is worth, as there is already a simpler method to do that by. -- ( 00:59, 9 September 2014 (UTC)

Seems rather stable, plus it seems some people noticed no longer is used, and have skipped adding it. <span class=nowrap>— ( 21:32, 3 October 2014 (UTC)


 * Yep, there's been no obvious issues, so I'll nuke it now. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 08:47, 4 October 2014 (UTC)

Outdated function in the code
There seems to be a few outdated and somewhat broken functions leftover in the code, namely setting the header to "details" (not used for the details table within a table) and "overview". Both when used make the title that of the aforementioned, and all version links break until another header is specified. Any reason to keep them? <span class=nowrap>– (·) 03:29, 28 January 2015 (UTC)


 * I recall there was a proposal to have it able to switch between two views: details (i.e., everything) and overview (basically just changes since the last release version, ignoring all the fiddling about within development versions). I can't find the original discussion or a demo, and it doesn't seem to have been fully implemented.


 * Incidentally, is there any page that still uses the nested tables? It always looked a bit ugly to me, and I don't think it's necessary with the current template features. -- undefined 07:18, 28 January 2015 (UTC)


 * The only page I remember the nested table being used on was, although that has since been removed, including on the translation projects. It would be rather easy to call up a list of all pages using it though.


 * And I forgot to mention previously that there also seems to be an outdated head function, which simply returns nothing. <span class=nowrap>– (·) 17:06, 29 January 2015 (UTC)


 * Currently, there are no pages that use the details header, as shown in the temporary category.
 * I created a sandboxed version of this template shown [ here], which removes the details mode and outdated headers, plus cleans up the code a bit and adds a few minor features (like easy pre-release linking). Are there any objections to implementing it? <span class=nowrap>– undefined/undefined 02:07, 9 April 2015 (UTC)


 * Alright, I've removed the details view, and the "details", "overview" and "head" modes. If anyone disagrees now, feel free to say so. <span class=nowrap>– undefined/undefined 21:38, 21 April 2015 (UTC)

No link
I think there should be a way to make a version so that it is not a link. On user pages, the user might want to tell the version to give readers an idea of when an event happened. I notice that there are 2 |'s after the word history, so maybe it could be something like link=false. 15:39, 22 February 2015 (UTC)


 * It is possible, use . Example:

– - 16:57, 22 February 2015 (UTC)


 * @71.35.109.25: Please try to read the templates documentation fully before requesting a feature, it states it on the documentation in the section "Versions" <span class=nowrap>– (·) 23:38, 22 February 2015 (UTC)

Broken 'slink' parameter
It doesn't seem to work for wikilinks or external links; it fails to display the link entirely when slink is not 'ver' or 'none'. –  undefined/undefined 16:15, 8 May 2015 (UTC)
 * I think I got it. –  undefined/undefined 19:49, 8 May 2015 (UTC)


 * Yeah, apparently I messed up the placement of a few brackets, causing the default to be moved to a third parameter of the "if unknown" declaration, and never noticed it due to the recent template cache issue. I went ahead and fixed another bracket I missplaced and remove the old misplaced statement. <span class=nowrap>– undefined/undefined 21:52, 8 May 2015 (UTC)

Better console edition versions
Since there are now three different version numbers for the console edition, shouldn't we list all three versions in the history section? We currently only list the Xbox 360 version unless it is exclusive to the Xbox One or PS.

I have a solution shown in ([ code]) which replaces the normal two columns with three, one for each of the console editions. It adds the additional parameters, , and to set the numbers for each version, and in the case of the playstation edition, it supports a bit of disambig for the two cases where two different versions have the same number.

So, would anyone be in support of this idea? If so, should we also add a category to mark pages using the old format for the console edition? <span class=nowrap>– undefined/undefined 22:36, 30 June 2015 (UTC)

Problem with console edition TU14
There's a bit of a dilemma with merging this to the new console format - as you can see on the page, the version TU14 corresponds with 1.04 for the Playstation version. The dilemma appears to only be for this version where the Playstation 3 version number is larger than the number that the PS4 version receives when it is released later, meaning that the history table in its current form seems a bit confusing ("how does 1.04 appear before 1.00?" - well 1.04 relates to the PS3 number while 1.00 relates to the PS4 number). Hopefully I've explained myself clearly enough and what is the best way to handle this problem, because what I've done on the page doesn't seem to make much sense from a reader's viewpoint. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em"> 10:22, 11 December 2015 (UTC)


 * I really am not sure what to do about this, as it really is Mojang's fault the PS version numbers are so different at first. I would add another column, but they sync up at 1.10 which would lead to redundant information then. The best idea I can come up with is to either specifically mark where it is a PS4 version instead of a PS3 exclusive one, or to add a fourth column that only shows before 1.10, of which both ways could be a bit confusing, but hopefully better than now. <span class=nowrap>– undefined/undefined 15:55, 11 December 2015 (UTC)

Remove header alises
Currently, just about every header has at least five aliases, and it would be a lot easier to both maintain this template and have my bot adjust headers upon update releases if the headers all had just one or two possible names. Would anybody argue with me deprecating and removing some of the redundant header names? <span class=nowrap>– undefined/undefined 21:46, 18 February 2016 (UTC)


 * I'd be fine with it, and I'm not particular about which ones we settle on. – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 22:00, 18 February 2016 (UTC)


 * From the looks of it, the one or two letter ones are the most used, so I'd keep those. The full names are also used by less frequent wiki visitors, but beyond that I'll most likely get rid of the rest. <span class=nowrap>– undefined/undefined 22:27, 18 February 2016 (UTC)


 * Is there any reason to use cryptic aliases instead of a simple name? Like  instead of   (???),   instead of , etc.? It's not like there are a ton of these on the page. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  03:34, 27 February 2016 (UTC)


 * Because they are easier to type? I mainly did not touch those ones since they were around for so long and commonly used (thus keeping just the shortest of the short names), and added  for the sake of consistency (and to replace its previous shortname of "ps3"). Since the history tables are only used once per page, I cannot think of any reason we really need the really short names other than that I'm used to them, so I don't see it being a problem deprecating the two character aliases in favor of just the full names (which it would also help new users in learning the history tables). <span class=nowrap>– undefined/undefined 18:56, 27 February 2016 (UTC)

There are no more pages in, apart from translation pages, which are. – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 19:24, 29 August 2016 (UTC)
 * At long last,

What about making the version names so they're non-breaking
I noticed that whenever you make the table small enough, the WiiU version 'Patch 1' will take two lines; 'Patch' then '1'. I thought it would be nice if the WiiU cell were non-breaking – but then I thought it might be nice if all the rest of the version links were non-breaking, such as 'Beta 1.9-pre6', so it wouldn't break into 'Beta' and '1.9-pre6'. In my thinking, there's no reason for header cells to make a row taller, if avoidable.

Now, do we have any exceptionally long version cells that still ought to split to multiple lines, that might make non-breaking an undesirable thing? – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 22:52, 24 February 2016 (UTC)


 * The only exceptionally long titles are the dates used in early development (pre-alpha) and the occasional link, it should be easy enough to set it to wrap if either of those conditions are met though (just don't wrap if the parenthesis are added or is set). I'll try to make something work once KnightBot finishes his current task (as I have to remove a category once he is done anyways). <span class="nowrap">– undefined/undefined 22:57, 24 February 2016 (UTC)


 * Oh yeah – links are what I'm thinking of. Yes that will probably catch all the cases.  Thanks!  –  <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 23:08, 24 February 2016 (UTC)


 * <span class=nowrap>– undefined/undefined 23:20, 24 February 2016 (UTC)

Use a module
The wikitext for this template is extremely complicated. We should use Lua.

<span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 14:15, 24 April 2016 (UTC)


 * Most of the complication here comes from the fact that the cell code is located in 6 different spots, once for each console version plus two for normal versions. That being said, making this a module would benefit the template as that can be converted into a function, I just have not found time to write something that is not, and that module with its current state it did not increase performance much either.
 * I have been making a few internal changes to the template recently aimed at making the code cleaner though, such as deprecating a lot of the excessive aliases (I would prefer not to have to mw.loadData it just because it is ridiculously long), and making all types cells use consistent "empty" and "merge" values. <span class=nowrap>– undefined/undefined 19:16, 24 April 2016 (UTC)

Category:Upcoming
For the 'Upcoming' and 'pocket edition upcoming' sections, could it be set up so it adds to the page? – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 12:09, 10 May 2016 (UTC)


 * They actually intentionally don't, as there should already be content on the page elsewhere if something is upcoming, and if not there is nothing really for a human to fix (a I normally send my bot to remove the headers once an update is released instead of manually doing it). Basically, it is a bit easier for a human to update things if they don't have a bot's to do list in the way.
 * If you want a list of pages that use either header though, there are subcategories of Category:Upcoming with those pages. <span class="nowrap">– undefined/undefined 22:57, 10 May 2016 (UTC)

Dates for version numbers
If a date and a version number appear in two adjacent rows, people who want to know the difference between the dates have to visit the version page. The same applies for two subsequent (not sure if that's the right word) versions, and even more for the same history entry for multiple editions.

I think it may be necessary to somehow integrate dates for versions into this template. Any ideas, objections or opinions? --, previously known as GreenStone 07:31, 19 May 2016 (UTC)
 * In principle I like it, as a usability feature. It is the 'history' section, after all.  Do you find yourself looking up dates a lot, like you said? –  <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 12:04, 19 May 2016 (UTC)
 * I often wonder what these dates are in comparison, but I'm probably too lazy to actually click the link and wait for the page to load so that I can read it. --, previously known as GreenStone 12:07, 19 May 2016 (UTC)


 * Could change the link's tooltip to be the release date? <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 01:59, 20 May 2016 (UTC)
 * Maybe, but I think this would need to be supplemented with either Tooltip formatting, a note above the table ("Hover over version numbers to see the versions' release dates" or something like that, with reduced font size), or even both. --, previously known as GreenStone 04:27, 20 May 2016 (UTC)