所有版本页面应符合以下布局,使版本页面的格式能保持前后一致。
标题[]
Java版[]
对于正式版,应该按照游戏主菜单左下方给出的版本号数字进行命名(例如使用“Java版1.0.0”作为标题而不是“Java版1.0”)。
对于预发布版,为保证其统一性,应该采用Java版<版本号>-pre<数字>
这个格式进行命名(例如Java版1.15-pre1)。
对于发布候选,为保证其统一性,应该采用Java版<版本号>-rc<数字>
这个格式进行命名(例如Java版1.0.0-rc1)。
对于实验性快照,为保证其统一性,应该采用Java版<版本号>-exp<数字>
这个格式进行命名(例如Java版1.18-exp1)。
对于快照,根据现有共识,不需要添加“Java版”前缀,只需要采用<年份>w<周数><发布次数>(a-z)
进行命名(例如20w06a)。
其余版本根据实际情况与共识另行规定。
基岩版[]
Demo-1.1此阶段是基岩版的前身,称为“携带版”并采用此作为前缀;从1.2开始采用“基岩版”前缀。
对于正式版,通常应该采用x.x.x
的三位数格式进行命名(例如携带版0.14.0),特殊情况例外(例如基岩版1.2.6.60)。
对于测试版,分为以下两种情况:
- 0.8-0.16的测试版,采用
x.x.x.a/bx
四位数格式进行命名,其中a
代表realms开发版本(例如携带版0.15.0.a2),b
代表常规测试版本(例如携带版0.16.0.b1)。 - 1.0及以后的测试版,采用
x.x.x.x
四位数格式进行命名,同时为了方便搜索不再在标题上区分alpha
和beta
(例如基岩版1.2.0.2)。
此外部分测试版也存在类似于Java版的发布候选版本,但是为了保证统一性并不会应用在格式命名中。
具体版本号数字按照游戏主菜单左或右下方给出的为准。其余版本根据实际情况与共识另行规定。
由于这是不同于英文Wiki共识的新规定,应该为今后新发布的测试版本创建一个带有beta
和Preview
的重定向(例如基岩版beta 1.16.0.57和基岩版Preview 1.19.60.23)。
简介[]
在此部分之前应当使用{{version nav}}
,模板中的|edition=
无需翻译。
若页面中包含了未确定官方中文译名的游戏内名称,应在消息框部分添加{{trans|un}}
。
在模板后应有带有常规描述的简要介绍。此描述应包含此更新的发布日期、正式名称(若有)、此版本的平台(Java版、基岩版等)和对应的开发阶段,以及对此更新的简要介绍。如果这是开发版本或测试版本,应说明这是哪个更新的开发版本或测试版本。
- 特别地,对于基岩版测试版中列出的平台名称,应以更新日志中列出的为准。对于正式版的,如更新日志未列出,则可参考时间相近的测试版的写法。
- 在信息框中,若需要并列多个平台名称时,应使用半角逗号后跟一空格的分隔符进行分隔。
如果这个版本被重新上传过,则应在介绍中列出重新上传的版本中的更改。如果重新上传的版本中更改很多(通常是Alpha前的版本),可以为重新上传的版本创建单独的页面;例如,从技术层面来说,0.31的每个版本都是首个版本的重新上传版本,但把它们全都放在同一个页面上会很丑。
简介示例[]
- 主要更新版本
1.10是霜炙更新的首个正式版,也是Java版的一次主要更新,发布于2016年6月8日[1]……
- 次要更新版本
1.14.1是Java版的一次次要更新,发布于2019年5月13日[2],此更新提升了性能和并修复了1.14的漏洞。此版本不兼容1.14的服务端。
- 开发版本(Java版)
18w43b是Java版1.14的第2个快照,发布于2018年10月24日[3],修复了18w43a中的漏洞。
- 测试版本(基岩版)
Beta 1.19.60.20(Android)、Preview 1.19.60.20(Xbox/Windows)是基岩版1.19.60的首个测试版,发布于2022年11月23日[4],同步了一些Java版的特性,在实验性玩法中加入了一些1.20.0的特性,并修复了一些漏洞。
- ↑ Minecraft 1.10: The Frostburn Update (存档),来自jeb_。 Mojang.com,2016年6月8日。
- ↑ “Minecraft Java Edition 1.14.1” – Minecraft.net
- ↑ "Minecraft Snapshot 18w43b" – Minecraft.net,2018年10月24日
- ↑ Minecraft Beta & Preview - 1.19.60.20 — Minecraft Feedback,2022年11月23日。
新内容和更改[]
新内容和更改这两个段落因为相似而在指导中合并,在实际的页面中要分成两个单独的段落。版本的主要更改应通过以下两个段落呈现:
- 新内容:版本中添加的任何新特性,也包括在开发版本中的特性。
- 更改:版本中对旧特性的任何更改,也包括在开发版本中的更改。被移除的内容应在此处列出,而非在单独的部分中列出——除非实在有很多。
如果此版本是正式版或包含很多特性,每个段落都应包含下列子段落:
- 方块:与方块有关的特性。
- 物品:与物品有关的特性。
- 生物:与生物有关的特性。
- 非生物实体:与非生物实体有关的特性,如盔甲架和矿车。
- 世界生成:与世界生成有关的特性。
- 游戏内容:与游戏机制有关的特性,如成就、状态效果、游戏模式和有关视觉效果的更改。
- 命令格式:与方块/实体标签或命令有关的特性。
- 常规:常规特性,如选项、闪烁标语和图像的更改。
如果特性还未在开发版本中出现,这些特性应归在单独的计划新内容和计划更改段落中。
被编号的更新或快照版本中的每一个特性都应该使用要点列表进行描述。对于任何新内容而言,这个列表应大体上全面,包括有关该特性的任何主要详细信息,但也应尽可能简明扼要,以便于阅读。大多数新内容应使用8个及以下(应很少超过12个)的要点描述。任何更改,以及罕见的在它们自己的页面上没有被描述的新内容,都应该包括所有相关的细节,甚至是次要的细节——尽管它们应该尽可能简短而不丢失任何信息。对于异常大的更改,如Java版1.13中的扁平化,拆分为单独的页面更为合适,并在版本页面上进行简要的总结。
有正式名称的更新页面,如水域更新,应当仅列出单独的新内容,而不描述其用途或行为,并尽可能简要地总结所有更改。
未确认的特性[]
除非信息来源充分,否则不建议添加此部分。此段落仅限正在开发的版本使用,只能包含以下特性:
- 不在这个版本(或任何特定版本)的计划或即将到来中;
- 在版本开始开发时已被以下内容证实:
- 一张能说明开发者为特性做工作的截图;
- 或开发者的叙述表明他们计划加入此特性 - 不仅仅是应答别人的想法。
此段落应由这些特性并未确认会在<版本>中出现,但他们被开发者在<版本>的开发过程中提及或展示。主条目:提及特性开头。
每个特性都应包含:
- 特性的名称或简要描述;
- 非细节,而是如何识别此特性(这些属于提及特性);
- 此段落的目的是使读者能识别未确认的特性,并说明理由 - 而不是介绍特性的细节。
- 一个简要的解释说明特性何时被提到以及为何未确认,加上能说明的参考。
修复[]
在Java版中,修复的漏洞使用{{fixes}}
。漏洞应该用下列开头组织成段落:
<母版本>
前正式版的漏洞(;old
)- 如果适用,应将其拆分为“1.x.0前正式版的漏洞”,如“1.x.0”、“1.x.1”的格式也适用于1.x.1及以后的正式版(例如1.14.3)。
<母版本>
开发版本的漏洞(;dev
)- 上个开发版本中的漏洞(
;previous
) - 当前版本的热修复漏洞(
;hotfix
) - 未公开漏洞(
;private
)
注意{{fixes}}
支持普通开头的快捷链接。
漏洞追踪器的漏洞标题可以自由编辑,以符合格式指导。我们鼓励用户在发现标题不符合格式指导时修复标题,但修复标题不是必要的——尤其是在首次添加加入时。编辑者可能会对标题进行很大的更改(例如改写整个标题),我们不鼓励这样做,除非初始的标题未能充分描述漏洞(例如,把“我发现了一个漏洞”改成“玩家在遇到方块时无法跳跃”)。
只有当解决结果已经明确标记为“已修复(Fixed)”时,漏洞修复才能加入到版本页面中。解决结果不是“已修复”的漏洞修复将被立即删除。
在基岩版中,除非官方更新日志没有明确分类,或无对应更新日志时应遵循Java版的格式,否则应当遵循下列格式(与官方更新日志中的格式一致):
- 类别1
- 漏洞描述1(漏洞编号1)。
- 漏洞描述2(漏洞编号2)。
- 类别2
- 漏洞描述3(漏洞编号3)。
- 漏洞描述4。
如官方更新日志中无对应漏洞编号,则无需填写。漏洞编号应使用{{bug}}
模板,例如:{{bug|MCPE-61166}}
。
Wiki帮助 | |
---|---|
页面规范 | |
常用页面 | |
社交媒体 |
语言