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)