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