You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.txt
+3-2Lines changed: 3 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -1,9 +1,10 @@
1
-
Version 4.0.6
1
+
Version 4.0.6.114041
2
2
3
+
* Adopt target-qualified four-component versions so Minecraft and loader compatibility can be identified from the mod version.
3
4
* Preserve generated worlds made with Mineralogy 1.10, 1.12, or 5.x by reading their saved mod metadata and exact legacy configuration before creating the OreSpawn world profile.
4
5
* Write human-readable, idempotent upgrade reports for legacy OreSpawn and Mineralogy imports while retaining source files and existing chunks unchanged.
5
6
* Audit automated runtime logs and dynamic-fluid generation so logged worldgen failures cannot pass merely because the process exits normally.
6
-
* Port OreSpawn 4.0.6 to Minecraft 1.14.4 and Forge 28.2.26 using Java 8.
7
+
* Port OreSpawn 4.0.6.114041 to Minecraft 1.14.4 and Forge 28.2.26 using Java 8.
7
8
* Fix provider top and filler materials being generated one block below exposed ground.
8
9
* Apply underwater materials from the corrected ground and ceiling materials to roof undersides.
9
10
* Preserve trees, vegetation, structures and block entities by running surface replacement before late features.
This document defines how versions are assigned to MMD mods.
4
-
It separates the version of the mod from the Minecraft version that the mod supports.
3
+
This document defines how versions are assigned to MMD mods and how an exact
4
+
Minecraft and loader target is encoded in a release version.
5
5
6
6
## Version format
7
7
8
-
Mod versions use three numbers:
8
+
Mod versions use four numeric components:
9
9
10
10
```text
11
-
Major.Minor.Bug
11
+
Major.Minor.Bug.Target
12
12
```
13
13
14
-
For example, OreSpawn `4.0.6` means major version 4, minor version 0, and bug revision 6.
14
+
The first three components describe the functional release. For example,
15
+
OreSpawn `4.0.6` means major version 4, minor version 0, and bug revision 6.
15
16
16
-
The final artifact or release may also identify its Minecraft version, such as `OreSpawn-26.2-4.0.6`. The Minecraft version is a compatibility target; it is not part of the mod's `Major.Minor.Bug` progression.
17
+
The fourth component identifies the Minecraft and loader target. A complete
18
+
release version such as `4.0.6.120061` therefore identifies both the OreSpawn
19
+
4.0.6 feature set and its Minecraft 1.20.6 Forge build.
17
20
18
-
When the Major or Minor component increases, the components to its right reset to zero. For example:
21
+
This is an expanded, Maven-compatible versioning convention. It is not strict
22
+
Semantic Versioning 2.0, which defines exactly three numeric core components.
23
+
24
+
When the Major or Minor component increases, the functional components to its
25
+
right reset to zero. The Target component is then appended for the build being
26
+
released. For example:
19
27
20
28
```text
21
-
4.0.6 -> 4.1.0
22
-
4.1.3 -> 5.0.0
29
+
4.0.6.120061 -> 4.1.0.120061
30
+
4.1.3.120061 -> 5.0.0.120061
23
31
```
24
32
33
+
## Target component
34
+
35
+
The Target component is deterministic and is not another feature or bug
36
+
sequence number.
37
+
38
+
To calculate it:
39
+
40
+
1. Normalize the Minecraft version to `major.minor.patch`, using zero when the
41
+
patch component is omitted.
42
+
2. Concatenate the Minecraft major number without padding, the minor number as
43
+
two digits, the patch number as two digits, and the one-digit loader code.
44
+
3. Use loader code `1` for Forge and `2` for NeoForge.
45
+
46
+
The component can be decoded from right to left: one loader digit, two patch
47
+
digits, two minor digits, and all remaining digits for the Minecraft major
48
+
version.
49
+
50
+
Examples:
51
+
52
+
| Minecraft | Loader | Target | Full OreSpawn 4.0.6 version |
53
+
| --- | --- | ---: | --- |
54
+
| 1.13.2 | Forge |`113021`|`4.0.6.113021`|
55
+
| 1.20.6 | Forge |`120061`|`4.0.6.120061`|
56
+
| 1.21.11 | Forge |`121111`|`4.0.6.121111`|
57
+
| 26.1.2 | Forge |`2601021`|`4.0.6.2601021`|
58
+
| 26.2 | Forge |`2602001`|`4.0.6.2602001`|
59
+
| 26.2 | NeoForge |`2602002`|`4.0.6.2602002`|
60
+
61
+
Historical MMD releases may also have four numeric components but may have used
62
+
the fourth component differently. This policy applies prospectively; it does
63
+
not reinterpret an old release number.
64
+
25
65
## Major version
26
66
27
-
Increase the **Major** number for a large-scale change, paradigm shift, or breaking change that moves the mod forward in a fundamental way.
67
+
Increase the **Major** number for a large-scale change, paradigm shift, or
68
+
breaking change that moves the mod forward in a fundamental way.
28
69
29
70
Examples include:
30
-
- Mineralogy 6 no longer containing its own world generation engine, unlike Mineralogy 5.
31
-
- OreSpawn 4 gaining a complete terrain generation engine, including strata, unlike OreSpawn 3.
32
71
33
-
Compatibility adaptations required to support another Minecraft or loader version do not by themselves require a major version increase when the mod's supported behaviour and public contracts remain equivalent.
72
+
- Mineralogy 6 no longer containing its own world generation engine, unlike
73
+
Mineralogy 5.
74
+
- OreSpawn 4 gaining a complete terrain generation engine, including strata,
75
+
unlike OreSpawn 3.
76
+
77
+
Compatibility adaptations required to support another Minecraft or loader
78
+
version do not by themselves require a major version increase when the mod's
79
+
supported behaviour and public contracts remain equivalent.
34
80
35
81
## Minor version
36
82
37
-
Increase the **Minor** number for a new feature or a significant change to existing behaviour that does not justify a new major generation.
83
+
Increase the **Minor** number for a new feature or a significant change to
84
+
existing behaviour that does not justify a new major generation.
38
85
39
86
Examples include:
87
+
40
88
- adding a new player-usable block or other substantial feature;
41
89
- substantially overhauling a world-generation engine;
42
-
- making a significant fix or adjustment that materially changes how a major part of the mod behaves.
90
+
- making a significant fix or adjustment that materially changes how a major
91
+
part of the mod behaves.
43
92
44
93
## Bug version
45
94
46
-
Increase the **Bug** number for a bug fix or a very small feature that does not materially change the mod's design.
95
+
Increase the **Bug** number for a bug fix or a very small feature that does not
96
+
materially change the mod's design.
47
97
48
98
Examples include:
99
+
49
100
- correcting a generation defect;
50
101
- fixing a user interface or compatibility problem;
51
102
- adding or correcting a language file translation;
52
103
- making a small documentation or configuration improvement that warrants a
53
104
release.
54
105
55
-
This component is sometimes called the patch number in other semantic version systems. MMD uses the name **Bug** to make its intended purpose explicit.
106
+
This component is sometimes called the patch number in other versioning
107
+
systems. MMD uses the name **Bug** to make its intended purpose explicit.
56
108
57
109
## Ports to new Minecraft versions
58
110
59
-
Porting a mod to a new Minecraft version does not automatically change the mod version. If the new branch is functionally equivalent to the source branch, both releases use the same mod version.
111
+
Porting a mod to a new Minecraft version does not automatically change the
112
+
functional `Major.Minor.Bug` version. Functionally equivalent ports share those
113
+
first three components, while their complete versions have different Target
Target MC/Framework specific implementation details may differ internally where Minecraft or its mod loader requires them. Those adaptations do not require a different mod version when users and integrations receive the same supported behaviour.
124
+
Target-specific implementation details may differ internally where Minecraft
125
+
or its mod loader requires them. Those adaptations do not change the functional
126
+
version when users and integrations receive the same supported behaviour.
69
127
70
-
If a port also introduces a feature or fix that changes the functional release, the version must be assessed using the Major, Minor, and Bug rules above.
128
+
If a port also introduces a feature or fix that changes the functional release,
129
+
the first three components must be assessed using the Major, Minor, and Bug
130
+
rules above. The Target component always identifies the build's actual
131
+
Minecraft and loader target.
71
132
72
133
## Branch-specific fixes and skipped numbers
73
134
74
-
Version numbers are allocated across the mod as a whole and must not be reused for unrelated functional change sets on different Minecraft branches. The same number may be shared by functionally equivalent ports, as described above.
135
+
Functional version numbers are allocated across the mod as a whole and must
136
+
not be reused for unrelated change sets on different Minecraft branches. The
137
+
same `Major.Minor.Bug` may be shared by functionally equivalent ports.
75
138
76
-
If a released branch receives a bug fix that other branches do not require, only the affected branch is incremented. For example, that branch may move from `4.0.6` to `4.0.7` while unaffected branches remain on `4.0.6`.
139
+
If a released branch receives a bug fix that other branches do not require,
140
+
only the affected branch's Bug number is incremented. For example, Forge
141
+
1.13.2 may move from `4.0.6.113021` to `4.0.7.113021` while unaffected branches
142
+
remain on their target-qualified 4.0.6 versions.
77
143
78
-
If a different branch later receives a separate fix, it uses the next unused version, such as `4.0.8`, even if the `4.0.7` fix was not applicable to it. A branch may therefore legitimately skip version numbers.
144
+
If a different branch later receives a separate fix, it uses the next unused
145
+
Bug number, such as `4.0.8`, even if the `4.0.7` fix was not applicable to it.
146
+
A branch may therefore legitimately skip functional version numbers.
79
147
80
148
This provides three useful guarantees:
81
-
1. A version number is not used to describe two different functional change sets.
82
-
2. A higher version identifies a later change in the mod's release history.
83
-
3. It is immediately visible that one branch may contain work not present in an older-numbered branch.
84
149
85
-
A higher version on another Minecraft branch does **not** necessarily mean it contains every lower numbered branch specific fix. Some fixes are relevant only to a particular Minecraft or loader implementation.
150
+
1. A functional version is not used to describe two unrelated change sets.
151
+
2. A higher functional version identifies a later change in the mod's release
152
+
history.
153
+
3. The Target component identifies the exact Minecraft and loader build without
154
+
overloading the functional version.
155
+
156
+
A higher functional version on another Minecraft branch does **not**
157
+
necessarily mean it contains every lower-numbered branch-specific fix. Some
158
+
fixes are relevant only to a particular Minecraft or loader implementation.
159
+
160
+
## Dependency ranges
161
+
162
+
Dependencies should normally express the compatible functional release range.
163
+
For example, Maven-style range `[4.0.6,5.0.0)` deliberately accepts all
164
+
target-qualified OreSpawn 4.0.6 builds while excluding OreSpawn 5.
165
+
166
+
Consumers must still declare their supported Minecraft version and loader in
167
+
their own metadata. The Target component makes that compatibility visible; it
168
+
does not replace loader-level compatibility checks.
86
169
87
170
## Release and pull-request documentation
88
171
89
-
Because maintained branches can legitimately contain different fixes, the version number alone is not a substitute for release notes.
172
+
Because maintained branches can legitimately contain different fixes, the
173
+
version number alone is not a substitute for release notes.
90
174
91
175
Every release and pull request should state:
92
176
93
177
- the Minecraft version and loader it targets;
94
-
- the mod version before and after the change;
178
+
- the complete four-component version and its functional `Major.Minor.Bug`;
95
179
- the features and fixes actually included;
96
180
- any fixes from nearby versions that are not applicable to that branch;
97
181
- whether the change is functionally equivalent to another maintained branch;
@@ -101,9 +185,17 @@ Every release and pull request should state:
101
185
102
186
When assigning a version, ask the following questions in order:
103
187
104
-
1. Is this a fundamental or breaking new generation of the mod? Increase **Major**.
105
-
2. Is this a substantial feature or significant behavioural overhaul? Increase **Minor**.
106
-
3. Is this a bug fix or very small feature? Increase **Bug**, using the next unused number across the mod.
107
-
4. Is this only a functionally equivalent Minecraft or loader port? Keep the existing mod version.
108
-
109
-
The objective is to make versions useful to players, pack developers, mod integrators, and release automation while allowing each maintained Minecraft branch to receive only the changes it actually needs.
188
+
1. Is this a fundamental or breaking new generation of the mod? Increase
189
+
**Major**.
190
+
2. Is this a substantial feature or significant behavioural overhaul? Increase
191
+
**Minor**.
192
+
3. Is this a bug fix or very small feature? Increase **Bug**, using the next
193
+
unused number across the mod.
194
+
4. Is this only a functionally equivalent Minecraft or loader port? Keep the
195
+
existing `Major.Minor.Bug`.
196
+
5. Calculate and append the Target component for the exact Minecraft and loader
197
+
build.
198
+
199
+
The objective is to make versions useful to players, pack developers, mod
200
+
integrators, release automation, and support teams while allowing each
201
+
maintained Minecraft branch to receive only the changes it actually needs.
0 commit comments