Replies: 8 comments 26 replies
-
|
SMBX 1.3 is just an asset name. This is NOT a direct SMBX Engine. |
Beta Was this translation helpful? Give feedback.
-
|
I think we should stick at 1.3.x as long as there is no support for major 38A and X2 features. As soon as 38A/X2 episodes can be played natively or ported easily (without tricky workarounds like in Star Scramble/NSMB Classic), it would be proper to have a version number higher than these. Imo, there is no need to rush, since that's more of a longterm thing. Also, not exactly relevant, but I feel it's still useful to mention here: I think 1.3.7 should be the version to introduce Netplay support. This will skyrocket the popularity of TheXTech instantly, making it likely to attract developers willing to port X2/38A features. |
Beta Was this translation helpful? Give feedback.
-
|
The other thing is, use 1.3.x.y for standard 1.3 features, higher of 1.3 (1.x.y.z) should be used for multi-features. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @0lhi on this -- let's let 1.3.6 be the update with multires, and 1.3.7 be the update with the next major feature (possibly netplay, or settings/compat rework if we see this as major enough). While the base game support remains SMBX 1.3, let's keep the major/minor version 1.3. The main goal of TheXTech is to faithfully reimplement the engine of SMBX, and using the version to indicate the standard we are targeting seems very reasonable to me. (We could do 1.4, 2.0, or 2.4 in the future if/when we support the appropriate base featuresets.) |
Beta Was this translation helpful? Give feedback.
-
|
Also, there are other awaiting or planned add-ons such as a font engine to print non-ASCII (and the translation system for the engine itself, and the non-destructive localization for episodes), lua scripting system, graphical backend update (to allow drawing any texture by Z-order) which is very important for a doze of graphical nifty features and for multi-layer backgrounds (that should be able to draw foreground parts, and draw parts among in-scene objects, not just behind of everything), etc. etc. etc. And so, speaking about standard extensions, they really could bump the major version from 1 to 2, etc., and we should be fine to bump minor version every set of biggies introduced. Additionally, I think, having a set of biggies in the next time (after porting existing devel-branch stuff), we should choose the plan which will make the next stable release, or which will be taken in the next version. And so, we can release stable versions more often, to give users new features and bugfixes quicker. |
Beta Was this translation helpful? Give feedback.
-
|
Speaking about the version, why we need to switch it, as an example of the SDL project, for many years since the release of SDL2, it had versions from 2.0.0 to 2.0.22, with a time it got many internal reworks, major updates, received lots of new functionality, etc. The whole versioning system was confused, the "major" was being a fixed 2.0, when in fact it got lots of new additions of API, etc. But the minor version wasn't changed, and since the recent time they switched the versioning system with the removal of the minor version and so, their next version is 2.23.1, and the next release planned is SDL 2.24. So, they took general versioning rules:
|
Beta Was this translation helpful? Give feedback.
-
|
How do you feel about doing a 1.3.5.9 Release with Autocode + Abstract Controls, but without Multires? I suggested this recently in Chat but the Bridge Bot had issues, so I don't know how the idea was received. |
Beta Was this translation helpful? Give feedback.
-
|
Separating TheXTech version number from the asset pack version number is an option. Not my favorite one, but something I would be okay with. In that case, we should wait until #291 to make the change. Once a |
Beta Was this translation helpful? Give feedback.
-
|
Right, I completely forgot that we have the release that pretends to be an SMBX version. (Before I knew about TheXTech, I downloaded an "SMBX 1.3.2" build that was actually TheXTech.) I think it might be useful to rename the release "SMBX.v1.3.xta.6.0.7z` or something like that? |
Beta Was this translation helpful? Give feedback.
-
|
Hmm. It's worth considering at least. Maybe |
Beta Was this translation helpful? Give feedback.
-
|
For Nostalgic Paradise, version numbering will be like NsPr.0.2.xta.Y.7z. |
Beta Was this translation helpful? Give feedback.
-
|
I see, Nostalgic Paradise 1.0 should feature basic assets (like Completed Tileset, Basic NPC, etc.). |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
So will be 1.3.10?! (Future Freestyle-version like custom NPC/Block) |
Beta Was this translation helpful? Give feedback.
-
|
Not a fan of using two digits next to each other :/ I kinda hope Lua support will be added after 1.3.7, which could justify jumping beyond 1.3.x. But this gives me an idea. Maybe we could change the last digit to a letter? Current version is 1.3.5.3. I had to look that up cause, who can remember 4 numbers? I can't. If we make another release before Multires, it could be 1.3.5.d? Would be easier to remember, would offer room for 26 small updates before changing the major version, and it wouldn't look as bad if we do ever get to the point of 1.3.10 (compare |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
Multires is before 1.3.6. |
Beta Was this translation helpful? Give feedback.
-
|
Anyway, Autocode and Abstract controls are too major features to be a small update of 1.3.5.x branch, and therefore I think, it's reasonable to release 1.3.6 with the current features set and then 1.3.7 with multires and other nifty stuff. Currently multires needs more testing/polishing until get an average stable state to be released in a stable update. We with @0lhi still thinking about how better to do this. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
Okay, just a small poll, which versioning number should be used after the 1.3.6 release? (react to this message to vote)
Note for new versioning model: As some people said about possible confusion because of version number shows the engine "surpasses" other engines so quick, it's not to compare. Every branch of SMBX has its own independent versioning model and every SMBX branch is known by a different name, not by version number. So: SMBX 1.3, SMBX-38A or 38A, SMBX2 or X2, and TheXTech. So, the different names of the engine should be enough to understand that it's a different engine with different features set. |
Beta Was this translation helpful? Give feedback.
-
|
@LoveBodhi I think there's a strong consensus that we should move away from "1.3.x" eventually. The question is what we should do for the next versions. If you want to keep .3 for now (I want the same), you should vote for the |
Beta Was this translation helpful? Give feedback.
-
|
I’m happy with keeping the 1.3 series for a while longer too. I’m in no rush for this! But it will be nice for us to separately consider what will come next. |
Beta Was this translation helpful? Give feedback.
-
|
Anyway, what if I add the basic lua support (with minimal functionality on the quick hand) after the 1.3.6 release? :) |
Beta Was this translation helpful? Give feedback.
-
Then .3 will be removed. |
Beta Was this translation helpful? Give feedback.
-
@ds-sloth Agreed. Sort of related, could you join Matrix later? There's an idea I'd like to discuss with you.
@Wohlstand While I'm SUPER eager to get Lua support, let's wait just a bit before making a decision. There's also another other thing to discuss, but best to wait until Merge to prevent things from getting overwhelming ^-^ |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
Hello!
This is a small discussion about the versioning system used by TheXTech. First, I want to explain the current system:
List of versions based on current versioning system:
However, as we discussed on Discord, there are several arguments to change the versioning system:
How the versions would go if I used the versioning system instead:
Anyway, switching the versioning systems will mean that the next version after the upcoming 1.3.6 will be 1.7 (basically, I'll shift version sections and bump the minor (Y) version from 3 to 7, and the third section (Z) will be used for minor updates without serious functional changes, and the fourth section (Q) will be used for hotfixes only over already released versions).
So:
Also, in theory, would be useful to use even/odd version numbers to separate stable and in-development versions. Currently, in in-development versions, I add the "-dev" suffix, which is enough to mark the in-development version states.
What do you think?
Beta Was this translation helpful? Give feedback.