Template talk:History

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. - Asterick6 (talk) 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). —Fenhl 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. - Asterick6 (talk) 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. —Fenhl 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. - Asterick6 (talk) 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. - Asterick6 (talk) 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. —Fenhl 07:52, 9 June 2012 (UTC)
 * What Orthotope said below was what I was trying to tell you about. - Asterick6 (talk) 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 Version history/Development versions 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. -- Orthotope 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. —Fenhl 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. -- Orthotope 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. –ultradude25 (T&#124;C) at 09:20, 9 June 2012 (UTC)


 * I don't even see mw-collapsible on Special:Version. 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? —Fenhl 09:34, 9 June 2012 (UTC)


 * mw-collapsible 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. –ultradude25 (T&#124;C) 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. —Fenhl 12:55, 9 June 2012 (UTC)


 * Exactly... it's broken. –ultradude25 (T&#124;C) 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? -- Orthotope 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. —Fenhl 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. –ultradude25 (T&#124;C) 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. —Fenhl 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. - Asterick6 (talk) 19:05, 9 June 2012 (UTC)

For example, Ice 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. - Asterick6 (talk) 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. - Asterick6 (talk) 22:14, 9 June 2012 (UTC)


 * The new version of the template will take care of all that. —Fenhl 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? --M0rphzone 01:09, 1 September 2012 (UTC)
 * Oh nvm, "unknown" takes care of that. --M0rphzone 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. —Fenhl 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? CRRaysHead90 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. –ultradude25 ᐸ Talk Contribs 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. CRRaysHead90 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? 74.94.156.113 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. 74.94.156.113 00:50, 6 February 2013 (UTC)


 * I have made a new version of the template (Template:History2) 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. –ultradude25 ᐸ Talk Contribs 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 GingerGeek 20:38, 19 February 2013 (UTC)


 * Added. -- Orthotope 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. Silivrenion 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. -- Orthotope 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 Emerald   20:28, 10 April 2013 (UTC)


 * Why can't we just simply start using Template:History2 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. –  Goandgoo ᐸ  Talk  Contribs  Edit count 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. –ultradude25 ᐸ Talk Contribs 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. –ultradude25 ᐸ Talk Contribs 09:45, 15 June 2013 (UTC)

Release versions in Upcoming section?
There's been a bit of an edit war between me and Matt 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? —Fenhl 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? –Matt ᐸ Talk Contribs ⎜ 05:49, 28 September 2013 (UTC)


 * It is misleading: 1.7 is not a released version of Minecraft yet, while the “1.7” on Minecart 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 Version history, which illustrates my point: it's just not there. Besides, as little space as it may take up, it still adds clutter. —Fenhl 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. –Matt ᐸ Talk Contribs ⎜ 08:04, 28 September 2013 (UTC)


 * I have edited the template docs to make this more clear. —F‌enhl 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. –Goandgoo ᐸ Talk Contribs Edit count 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. –Matt ᐸ Talk Contribs ⎜ 09:44, 2 March 2014 (UTC)


 * Ok, thanks for the reply. –Goandgoo ᐸ Talk Contribs Edit count 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:

—F‌enhl 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 –Matt ᐸ Talk Contribs ⎜ 14:24, 5 March 2014 (UTC)


 * Here's a mockup of the different variants. I think the “everything colored, same table” one looks best. —F‌enhl 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. –Matt ᐸ Talk Contribs ⎜ 03:16, 18 March 2014 (UTC)


 * I also prefer headers only, the rest seems a bit busy/too colourful. –Goandgoo</b> ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>Talk Contribs Edit count 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? –Goandgoo</b> ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>Talk Contribs Edit count 07:05, 18 March 2014 (UTC)


 * According to the Achievements 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.) —F‌enhl 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

--<font color=#048>KnightMiner  (t 15:15, 3 September 2014 (UTC)


 * So I went ahead and added it, after remembering Category:Fixme --<font color=#048>KnightMiner  (t 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. --<font color=#048>KnightMiner  (t 04:35, 7 September 2014 (UTC)