Template talk:Java Edition versions

Redo snapshot lists
Basically, with the way snapshot lists are currently done, it causes it to stretch out of the side of the article on smaller monitors. Most recently it has even started stretching out of my monitor. I suggest we change the format slightly, maybe something like this --KnightMiner  (t 15:34, 2 August 2014 (UTC)


 * While your idea does eliminate the problem of it stretching out of the page width, it does lead to a couple of potential problems. Firstly, there is now a lot of white space (probably more than there is text). Secondly, once all the versions of minecraft pc are added to the table, it will get very long and impractical. Do you have any ideas to solve these problems? –Goandgoo ᐸ Talk Contribs Edits 23:35, 2 August 2014 (UTC)


 * Some of the whitespace can be removed by only giving headers to versions with snapshots, and stowing all the rest below. The only problem with that is the dpl template hates having multiple lists... Had to add them manually. With the afterwards updates, the most any seems to have is four pre-releases. Anyways, what that would look like. --KnightMiner  (t 01:02, 3 August 2014 (UTC)


 * Looks better, but is there any way to alter the linking templates so the versions don't need to be manually added? Also, I'm a bit confused why there are so many different templates (MinorVersionList, Development version list and snapshot list) - I noticed on your sandbox you're using the development version list template, but currently its using the snapshot list and minor version list? –Goandgoo ᐸ Talk Contribs Edits 01:29, 3 August 2014 (UTC)


 * Snapshot list is an alias for development version list. It is the same, only it adds the snapshot arg automatically instead of an option for snapshot or pre-release.
 * MinorVersionList was Sealbudsman's attempt to remove versions from the template in a similar way to Snapshot list. The major problem with it is you are just sending people elsewhere to add the information, and it is only being used on the navbox currently.
 * The main reason I did not use MinorVersionList was it would need to be modified for the demonstration, which is hardly simple to do without breaking current usage, and I used development version list over Snapshot list simply to make it more recognizable.
 * As for making it automatic, the only problem is that the versions are sorted by name, causing a bit of trouble for that. Anyways, major updates don't come out too often to make it much of a problem to update.
 * --KnightMiner  (t 01:49, 3 August 2014 (UTC)


 * Ok, thanks for clearing it up, it makes more sense now. You can probably transfer over your demo to the actual template now as I don't have any other objections. –Goandgoo ᐸ Talk Contribs Edits 01:56, 3 August 2014 (UTC)


 * I'll likely wait until tomorrow for that, to see if anyone else has any suggestions/objections. I also want to try and fix that weird list thing caused by dpl first (between snapshots and pre-releases it misses a bullet point). --KnightMiner  (t 02:30, 3 August 2014 (UTC)


 * as for MinorVersionList, feel free to collapse it back into the page or supersede it With something else, by all means. – Sealbudsman (Aaron) (talk) – 12:14, 3 August 2014 (UTC)




 * The wrapping (or lack of it) problem is caused by the  CSS not properly accounting for sublists - the entire contents of the list item for 1.6.1 has the CSS   applied to it, instead of allowing the sublist to break between items as the parent list does. Without looking at the CSS, I can't say how to fix it, though (and at half past 5 in the morning, it's a bit late for me to go looking more closely).
 * My original idea for the template was very close to your proposed solution, KnightMiner, actually. But I don't know what the long-term plans/expectations of other editors might be. Even if we go with it, though, the  CSS should be fixed to properly wrap sublist items. 「 ディノ 奴  千？！ 」? · ☎ Dinoguy1000 10:44, 3 August 2014 (UTC)


 * I implemented it from my sandbox, after adding the names back into the extra space.
 * Currently it does not use MinorVersionList, but if we need it in the same form in multiple pages, we can re-add it. I mainly left it out to make it a bit easier to change around for the time.
 * As for the wrapping, I think the nowrap was added since it looks better for smaller lists, and it was not intended for larger lists. It would look a little odd to break that halfway through. --KnightMiner  (t 19:54, 3 August 2014 (UTC)

Name for post-beta period
I noticed with Dinoguy's recent edit that he suggested Minecraft 1.0 should refer to the whole post-Beta period, and 1.0/1.0.0 refer specifically to the version 1.0. However I disagree; 1.0 seems like a version number, rather than a set period, and using Minecraft 1.0 for the whole period and 1.0 for the version seems rather confusing. I therefore suggest that the post-Beta period could be called Release, Post-Release or Post-Beta. Any thoughts, suggestions, objections etc. appreciated. –Goandgoo ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>Talk Contribs Edits 09:22, 5 August 2014 (UTC)


 * My plan is to eventually add 1.0 like was done with the rest (listed as 1.0 release), and leave the development cycle as the first group. --<font color=#048>KnightMiner  (t 14:14, 5 August 2014 (UTC)


 * The main problem here is really lack of official terminology: to my knowledge, Mojang have never given an official name for the entire post-Beta development phase. This leaves us with the problem of picking something for ourselves, and it has to satisfy several points: it has to be concise, unambiguous, and reflective of the nature of the phase. While I don't claim to have given this a considerable amount of thought, the conclusion I draw from the thinking I have done is that, assuming we clearly identify the difference between "Minecraft 1.0" and just "1.0", and consistently and accurately use the appropriate term everywhere, "Minecraft 1.0" is probably about the best we can do ourselves (though I am open to suggestions for alternate names). In addition, the way Minecraft 1.0 is currently written suggests that the article is meant to cover the entire development phase, as opposed to just the 1.0 release specifically. I do not believe "Release" or "Post-Release" meet the criteria I identified above satisfactorily, since "Release" could be applied to any development phase with publicly-released versions, and "Post-Release" to any such phase except for Classic (as the first phase with publicly-released versions); I also don't like "Post-Beta" because it suggests, at least to me, that this is just some minor development phase, as Pre-Classic was.
 * We could, of course, just avoid this debate entirely by twisting Mojang's arm asking politely (:razz:) and having Mojang decide on an official name to apply specifically to the current phase of development; maybe it would justify opening a ticket in the issue tracker? (I honestly don't know, since I don't actually browse the issue tracker enough to have a sense for how requests for features, enhancements, and the like are generally received.) 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 08:34, 10 August 2014 (UTC)


 * Hmm, I've tweeted the developers and hopefully I'll get a response. I don't think opening an issue on the issue tracker is really the right way to go because this is not really an issue as such. If I don't get a response, I think using Minecraft 1.0 as the development stage should be ok. –Goandgoo</b> ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>Talk Contribs Edits 09:04, 10 August 2014 (UTC)


 * If you don't get a response, I would still argue for opening a ticket - the worst that can happen is that it is closed as invalid (well, I guess it could simply be ignored entirely), and any response to the ticket would indicate that at least one of the devs has seen it and given it enough consideration to perform said response. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 09:25, 10 August 2014 (UTC)


 * Ok, are you able to post this to the issue tracker? I've never submitted any issues myself, not really sure how to use the tracker. –Goandgoo</b> ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>Talk Contribs Edits 09:52, 10 August 2014 (UTC)


 * I've only browsed in it myself; I don't think I've even created an account in it yet. If no one else does, I can have a look at filing a bug later, though again, I'm going to wait and see if your tweet bears fruit first. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 10:20, 10 August 2014 (UTC)

1.2 icon
I suggest a zombie head, since 1.2 brought the zombie seiges, and the AI update, – Sealbudsman (Aaron) (talk) – 13:14, 8 August 2014 (UTC)


 * . A little more significant than the redstone lamp. --<font color=#048>KnightMiner  (t 23:04, 9 August 2014 (UTC)


 * Zombie siege and AI update is significant as main feature, but does classic zombie tell us any new feature as an icon, no, so i suggest jungle thingy icon (tree, sapling, or ocelot) Afif Brika1 (talk) 05:08, 10 August 2014 (UTC)


 * I actually like Afif's suggestion: 1.2 introduced the Jungle biome, a major new biome, in addition to its rewrites of mob AI; by my measure, these were probably the two most important strictly-gameplay-oriented changes introduced in this version, and I feel that using the ocelot as the icon would allow us to represent both of them. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 08:38, 10 August 2014 (UTC)


 * As per Dinoguy's comment above I think ocelot is the way to go. –Goandgoo</b> ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>Talk Contribs Edits 09:04, 10 August 2014 (UTC)

Crowded Infobox
I've noticed recently the navbox has gotten very crowded. I could shorten it a bit by substituting the devolopement versions (the template does not like hlists, but substituted it would work), but other than that I cannot think of much else to do. --<font color=#048>KnightMiner  (t 23:04, 9 August 2014 (UTC)


 * I'm not really sure what you're saying here. While the navbox does cover a lot of ground, it is not what I would call "crowded"; the links are divided logically into reasonably-sized groups, meaning it should be quite easy to find a particular link you might be looking for. And the whole reason the manually-maintained lists of development versions were replaced with Snapshot list &co. was to automate those lists, so they wouldn't have to be manually updated whenever a new version was released. I wouldn't necessarily be opposed to removing the automation for older versions that will never have new dev versions released for them, but I don't think we really need to worry about doing so unless using the automation is shown to be problematic in some way that can't otherwise be addressed (and yes, I am fully aware that most of the automated lists have already been replaced with manual lists, and am also aware of the line-break problem between the lists of weekly snapshots and prereleases). And lastly, I don't have any idea what you mean when you say the template does not like hlists: which template, and how does it not like them? If you're referring to the line-break problem I just mentioned, that is, I suspect, a problem with whitespace in the template(s), and not one with either the templates themselves or with the hlist CSS. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 08:46, 10 August 2014 (UTC)

Child navboxes
I've made a preliminary version of this navbox where it would use child navboxes for the specific development phases, to allow the links related to each phase to be selectively shown or hidden. This will especially be useful as versions for Beta and earlier are spun out into their own articles and subsequently linked from here, though I don't know if others would prefer some other solution (the most obvious one, I think, would be separate navboxes for each version, though I personally don't particularly care for that). I'm aware of the spacing issues on the right side of the child navbox, but wasn't able to figure out what was causing them or how I might fix them in the few minutes I spent playing with the CSS. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 08:52, 10 August 2014 (UTC)


 * Interesting you should mention this, I was asking Majr on his talk page whether I should start converting Beta versions and earlier. He suggested that alpha and earlier probably doesn't need to be split up as there is not that much info per version. However he wasn't sure about converting beta - some beta versions (Beta 1.8 in particular) are super long, so they may justify a split. Also, I have converted the Beta 1.8 pre-releases to the new format.
 * In regards to the table mockup, I think having a table in a table is kind of weird aesthetically - I'm not sure how it would look with multiple development stages. I'm not really a fan of the double border on both sides and the bottom which is a result of the table in a table. Have you seen any good examples of a table in a table idea so you can persuade me? –Goandgoo</b> ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>Talk Contribs Edits 09:04, 10 August 2014 (UTC)


 * While I had just assumed we'd spin out separate articles for all releases, I never had a particularly strong opinion about it, and even now am rather ambivalent on whether we want to, or if we only want to go back to a certain point, and if so, where that point is. I will point out, though, that it is far more straightforward to add images to an article than it is to do so in the middle of a table, in the event we want to start illustrating individual versions with images that demonstrate exemplary features or characteristics of those versions.
 * Most of the problem with how the table-in-a-table (which is really more properly described as navbox-in-a-navbox) looks here is that our simplified navbox styles don't properly handle cases of child navboxes, as the "canonical" styles first developed and currently used on Wikipedia do (and the fact that, as I said, I only spent a few minutes toying with the styles in my sandbox before saving doesn't help matters any, either). You can see an example of how nice the canonical styles look with Wikipedia's Template:Pharaohs: a careful selection of color palette, along with removing the borders of the child navboxes, makes a world of difference. =) 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 09:22, 10 August 2014 (UTC)


 * Ok so if we are to go back to a certain point for the version articles, I think (personal opinion only) that Beta should at least be converted, not really sure about what to do before Beta though.
 * The Pharoah template looks really nice, would changing the styling on our navboxes be too difficult? I like how that template has no borders on the navboxes inside navboxes and how it sits nice and flush. In your initial post, you mentioned that phases can be selectively shown/hidden - so on a Beta version article, you can make it so that it hides the Minecraft 1.0 section? And vice versa for 1.0 articles? How do you achieve that? –Goandgoo</b> ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>Talk Contribs Edits 09:50, 10 August 2014 (UTC)


 * Conceptually, it would be as easy as replacing our navbox CSS with Wikipedia's, but practically, either the styles or our Navbox and SimpleNavbox templates would probably have to be adjusted to work properly here (but only one or the other, and only because Wikipedia's styles were developed hand-in-hand with their navbox templates, as our styles and navbox templates were here). There would also be the issue of color scheme: the color scheme we use for our navboxes is functional, certainly, but very little besides; this may be (and, indeed, probably is) personal bias talking, but I've always preferred Wikipedia's light blue-gray navbox color scheme (this would also not preclude us developing our own, more Minecraft-themed color scheme, or even going beyond just colors, so long as the resulting styles were still properly accessible). Even ignoring color scheme, though, I've always preferred some of the other characteristics of Wikipedia's styles (especially some of the padding) over our own, and beyond even that, Wikipedia's styles were very extensively tested for maximum browser compatibility and accessibility, whereas ours are much more ad-hoc (not to disparage the work of those who developed our version, of course).
 * And yes, that would be managed in one of two ways: a parameter (which, depending on its value, would have both, one, or neither of the child navboxes collapsed), or built-in logic to automatically collapse the appropriate child navbox according to the page (though this would still need a parameter to override where we want something else, or to specify for pages that aren't handled automatically by the logic). Both of these would require some changes to SimpleNavbox, though, I think. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 10:18, 10 August 2014 (UTC)