Jump to content

The 1.19.2 Dilemma


Curle

(Please read the content of the post first!)  

254 members have voted

  1. 1. Should we keep 1.18.2 as our LTS version, or move to 1.19.2?

    • Keep 1.18.2 as LTS, drop 1.19.2 entirely.
      127
    • Make 1.19.2 the LTS, drop 1.18.2 entirely.
      127

This poll is closed to new votes


Recommended Posts

Forge works on a Latest + LTS maintainence policy: we support the latest version of the game, and one other.

Currently, the latest is 1.19.3 and the LTS is 1.18.2.

However, 1.19.3 brought a lot of breaking changes in the game's code, which created a "barrier" of sorts when maintaining mods. It essentially needs to be treated as a separate version entirely from 1.19.2.

We cannot support all 3 (1.18.2, 1.19.2, 1.19.3) at the same time, and we are committed to supporting the latest, so we have a choice: keep our LTS as it is, or change it to 1.19.2.

It is important to note that this is more than likely not the last time this is going to happen. Mojang recently implemented something called "Feature Flags", which more-or-less allows features to be added in a minor version, bug tested, fixed and polished, before being activated in the next major release.

We expect that this will cause major breaking changes in lots of minor updates, so the decision here will set a precedent: if we go the route of supporting 1.19.2 and 1.19.3, we'll more than likely change the way the LTS system works entirely; supporting only the most recent major and minor versions.

As an example of what I mean: come the release of 1.21.5, we'll be supporting 1.21.0 as LTS, and 1.21.5 as latest. In all likelihood, there will be significant code change between the two, based on patterns we've observed so far.

We are unsure where to go, so we decided to put this decision to the community: this poll will last about a week, and the most popular option will be the route we take.

Link to comment
Share on other sites

Some observations:

  • If Mojang had content to go along with this, it would almost definitely have received the 1.20 version number, in olden days.
  • This may be the beginning of a new paradigm: all future dot releases (1.20.1,1.20.2 etc) will likely be major breaking changes, with the only viable "long term" version becoming the .0 version - where all the previous version's in-development features "go live".

This is seriously screwed up by Mojang.

Link to comment
Share on other sites

I'd say in general that dropping 1.18 is the better option. Not because 1.18 is an old version that needs to die, but rather because I think the LTS should serve as a gap between technical changes between versions. It probably seems more likely for someone stuck on 1.19.2 to have trouble moving onto 1.19.3 if the LTS version didn't stick with it and provide updates that can help the modder in question bridge their mod to the newer version. But yeah, incredibly scuffed versioning schema from Mojang nonetheless.

  • Like 1
  • Thanks 1
  • Sad 1
Link to comment
Share on other sites

As a note, the plan is to have 1.19.3's first RB be January 1st. Because I like that date and it gives people time to look at things during Christmas break. So this poll will stay open until that time and be what we do.
 

  • Like 2
  • Thanks 1

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

It feels quite weird. I think it would be really confusing for people to treat 1.19.2 and 1.19.3 as separate versions. On the other hand from a programming perspective it makes a lot of sense. I wish all modders could just update to 1.19.3 asap and we forget about 1.19.2. There are quite some changes, but it is doable.

  • Like 1
Link to comment
Share on other sites

I feel like making the .0 version LTS is risky because judging by the past .0 versions contain more bugs than other versions. My suggestion would be having the latest version of the previous major version (1.18.2) as LTS and the latest of the current major version (1.19.3) as current and adding the previous minor version (1.19.2) as a sort of MTS that gets unsupported as soon as a new version (major or minor) drops.

  • Like 3
Link to comment
Share on other sites

The point of this is that we believe Mojang is changing how they do versioning.

.0 versions going forward seem like they're going to just be moving all the features they add in minor versions into the normal feature set.
So, they'll have the same amount of bugs (since the code and items and blocks and etc are already there) but more features than the last minor (since they're still in feature flags).
Therefore, it makes more sense to have the major version be the LTS: same bugs, more content.

Link to comment
Share on other sites

From a user standpoint, I don't see much reason to use 1.19.2 over 1.19.3. The lack of content changes means there is no reason to not migrate to 1.19.3 other than mods that never got a chance to update (and to me, it seems unlikely someone who jumped on 1.19.2 would not also jump on 1.19.3)

On the other hand, 1.18.2 has been around long enough to build up a decent select of mods. I would rather give it more time for those mods to stabilize and expand then have another short-lived LTS version.

Edited by KnightMiner
  • Like 6
Link to comment
Share on other sites

This is quite a dilemma. To players, "previous version" = decrement the minor version number, but for Mojang not so much anymore.

From a feasibility standpoint, I don't think there is any clear cut way to do this. My main idea is "when there is a breaking change from the previous version, push LTS forward". This, naturally, shortens how long any given LTS version lasts - it may not be a bad idea to rebrand "LTS" into something like "Legacy Support" - "Long-Term Support" implies there is a plan to continue its development for a significant amount of time, which will no longer be possible under this specific methodology.

Another alternative is community support for developers on the previous minor version, like have an official Forge-backed Legacy Support version i.e. "Minecraft 1.19.3 is out, but we also support 1.19.2 as LTS/LS" and an additional community board "We also recognize developers using 1.18.2, however this is purely community backed. We will not provide direct official version support here". That's what seems sensible enough to me if the "long term" part of LTS is what matters more than just maintaining more than one version.

Check out my website!

Link to comment
Share on other sites

Typically when I think of a long term supported build of any piece of software etc. I think of the last stable version of the PREVIOUS major release. This makes a lot of sense for forge overall. It should stay as 1.18.2 until 1.20 is released, at which point lts should be changed to 1.19.x, gives the lts about a full year of support. 

  • Like 1
Link to comment
Share on other sites

I can appreciate the conundrum this is creating for Forge and the need to make a decision.

However; I believe another aspect that needs serious consideration and focus is the balancing of LTS to serve the needs of the 'large mod' devs and the modded community QOL vs the eternal chase of the newest shiny version number. If "LTS" is going to start changing even faster than it used to and end up on the same Major version as Latest then "LTS" will no longer have any useful meaning and should just be called something else so as to not be mocking everyone.

I have known several mod devs over the last decade who finally gave up modding even though they loved it because of the constant version grind. They were working on large mods that had great potential for even more development but it felt to the devs like they were spending most of their time updating their mods for the next version instead of being able to work on the features and improving the infrastructure.

Sure, updating simple mods as well as essentially complete mods may not be too bad most of the time, except for when more "game-breaking" changes are made by Mojang which affect their mod. But even then it becomes a ridiculous maintenance chase which is not at all conducive to the development of new and improved mods.

One aspect of Minecraft modding that has singularly contributed so very much to the modded experience and development are the `Mod Islands` that we are all familiar with. Examples being; beta 1.7.3, 1.7.10, and 1.12.2. Of which I believe 1.18.2 could be a great choice for the next one for various reasons. Modding was able to continue and build up on these levels permitting a large and varied selection of mods and experiences for players as well as time for developers to work on large mod projects which are amazing. These are Modded Ecosystem versions of Minecraft.

I hate asking anything that would make more difficulty for your team, but I sincerely believe that another LTS level, perhaps VLTS (Very Long Term Support) or ELTS (Ecosystem Long Term Support), that could be attached to a selected final Major version which has certain qualities, would contribute an incredible amount to the Minecraft Modded community, both for the mod devs as well as the community members looking for a stable/large & varied mod ecosystem that can offer them more than just the handful of new baubles that a new rolling and buggy mc version will give them.

I'd argue that the people Most concerned with always playing the bleeding edge version of mc are not the only ones who the entire modding system and community should be bent to serve at all costs. Doing so at the expense of what I spoke about in the last paragraphs would do the entire community a great disservice and knee-cap the best possible mod development. Please consider VLTS/ELTS, or at the very least keeping LTS as the final version of the prior Major version for some sane degree of mod community and dev stability. This will have benefits far outweighing trying to maintain some past rules technicalities at the expense of the entire purpose of the project and community.


Thank you for all you have done over the years and are planning to continue doing. We all owe you a great debt of gratitude.

P.S.    Adding ELTS could be considered a mod community investment project; creation of a Stable Nursery for new mod and mod ecosystem development.

This would be an incredibly attractive place for devs to be able to catch their breath and just focus on pure mod development, and for players to just build and enjoy collections of mods with increasing options for more mods and synergies without the dark pattern of feeling like they have to jump to the newest "version" of mc pulling at them as much, which makes them lose mods again and again which actually reduces the draw of modded vs vanilla.

tbh; The modding community shouldn't be run into the ground by the marketing needs of Mojang and Microsoft. They have their legitimate concerns and things they need to do, but those are not the same thing as what best serves the modding community.

Edited by MineCrak
Added ELTS references + P.S.
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Our stance will always be to be on the latest version. So we will always have to be on that update grind. Unfortunately that's just how modding a closed source game works. People will always throw fits no matter what we do. Us supporting one older version has been decided feasible enough for us to do. So whatever we call this secondary support version, there will only ever be one. There is a history of external things changes causing older versions to break especially in the development side {Gradle is a wonderful system that has no bugs or stupid design decisions...} We have had a bunch of people saying that we should support older developmental versions. We have given those people the option to step up and help with the manpower requirements to do that support. The RetroGradle project, they have not done that. So I don't see expanding dev support to more versions, even if community based, would be viable.

As for the modding plateaus. They are great for the community. Having one version of Minecraft with a ton of supported mods are great. However, these plateaus typically come from a handful of mods not updating. Combined with random packs using those mods becoming popular via youtube, twitch, or whatever. There really isn't anything we can do to predict when that'll happen. Unfortunately, none of us have actually functional crystal balls. So we got to pick something. The other problem is that IF we DID pick say.. 1.18.2 as the next "we'll support it for 2 years no matter what Mojang does" all it would take is one popular modder/youtuber to pick a 1.19.1 mod to make that choice moot. 

Aside from that, this is a is a potentially one off vote. Mainly because this is potentially the first in Mojang's new mantra. IF things go the way they have described. With minor versions being code breaking by introducing features via feature flags. Then using the Major version as the 'enable these feature flags by default'. Our new marching orders may be to only allow '.0' releases as LTS. For those who arnt getting what i'm saying. In the past we have had release candidate versions, that then switch to full releases. Here is an example of 1.17's RC to release changes:
 

diff -r -u3 versions\pre\1.17\1.17-rc2\projects\joined\src/main/java/net/minecraft/DetectedVersion.java versions\release\1.17\projects\joined\src/main/java/net/minecraft/DetectedVersion.java
--- versions\pre\1.17\1.17-rc2\projects\joined\src/main/java/net/minecraft/DetectedVersion.java	2021-06-08 09:30:16.357996900 -0700
+++ versions\release\1.17\projects\joined\src/main/java/net/minecraft/DetectedVersion.java	2021-06-08 09:55:02.419312200 -0700
@@ -29,9 +29,9 @@
 
    private DetectedVersion() {
       this.f_132478_ = UUID.randomUUID().toString().replaceAll("-", "");
-      this.f_132479_ = "1.17-rc2";
-      this.f_132480_ = false;
-      this.f_132481_ = 2723;
+      this.f_132479_ = "1.17";
+      this.f_132480_ = true;
+      this.f_132481_ = 2724;
       this.f_132482_ = SharedConstants.m_136192_();
       this.f_179761_ = 7;
       this.f_179762_ = 7;
diff -r -u3 versions\pre\1.17\1.17-rc2\projects\joined\src/main/java/net/minecraft/SharedConstants.java versions\release\1.17\projects\joined\src/main/java/net/minecraft/SharedConstants.java
--- versions\pre\1.17\1.17-rc2\projects\joined\src/main/java/net/minecraft/SharedConstants.java	2021-06-08 09:30:17.929174300 -0700
+++ versions\release\1.17\projects\joined\src/main/java/net/minecraft/SharedConstants.java	2021-06-08 09:55:03.744839600 -0700
@@ -10,11 +10,11 @@
 
 public class SharedConstants {
    @Deprecated
-   public static final boolean f_142912_ = true;
+   public static final boolean f_142912_ = false;
    @Deprecated
-   public static final int f_142951_ = 2723;
+   public static final int f_142951_ = 2724;
    @Deprecated
-   public static final String f_142952_ = "1.17-rc2";
+   public static final String f_142952_ = "1.17";
    @Deprecated
    public static final String f_142953_ = "1.17";
    @Deprecated
@@ -156,7 +156,7 @@
    }
 
    public static int m_136192_() {
-      return 1073741859;
+      return 755;
    }
 
    static {

As you can see functionally nothing has changed. It's just setting flags. IF future '.0' versions are like this. Then it would make sense for us to make the .0 our LTS vs the 'last version of the old major'. But ya we'll see what happens when Mojang releases 1.20.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

I think the definition of "support" is also important here, it's not like the user-level downloads or modder-level mavens get taken down (i've been rather loud in the past when they were), there's still people like myself working on 1.7.10 and 1.12 projects despite the unsupported nature, and it's functional, which is sufficient enough imo.
There's no tech support on older versions, granted, but honestly there's better places for that anyway, and if you're going to be modding long enough, eventually you'll have to get used to sifting through the decompiled source and making up your own answers anyway.

supporting 1.18 vs 1.19.2, i think it's better to look at things as they are now, and as they have been historically, again as Lex said, none of us have a magic crystal ball, so the best we have to go on is history, since it likes to repeat because humanity doesn't learn.
The greatest examples being during the 1.12.2 releases or the 1.7.10 release, both on the heels of a user-level identical release that few really paid attention to (1.12.0 and 1.7.2), with more active communities a little further back (1.11 and 1.6.4), more likely than not I anticipate this would be more of the same, and since forge is more aimed at chasing the latest as Lex states, latest will always be the real focus, so the secondary one should probably be the one that's older, since it would be easier to cover with more people knowing answers questions, and having more questions already answered in existing posts, otherwise both forge and mod devs are chasing two perpetually moving targets, especially in the case of new projects that are absolutely massive like Create was at one point, having all that work starting from scratch in addition to having to constantly chase every time mojank farts is unreasonable which is why mod devs will stay on a major version until they feel their main goals are reached. That's not to say forge doesn't have similar troubles itself, but more-so to amplify there's a shared issue.

The skeptic in me would say a simpler solution long-run would be having API level access structures, rather than relying on mojank's direct structure since they can't just stick with one way to do literally anything and it's all data anyway so interfacing one format to another doesn't make a real functional difference when done right, BUT, that's not really the question being asked, or the design of forge, there's other projects to cover that, things like FCL, UMC, and.... uh, actually, i probably can't say that last one im thinking of for a lot of reasons so, if you know, you know.

TL;DR, probably better for everyone to let a slightly older version stew, rather than chasing two moving targets.

Link to comment
Share on other sites

My personal opinion in this one might have been stated multiple times, but I think there is no need to stay on 1.18.2 if there is a newer version full of content. 1.19 added an entire new biome called the deep dark, and people have already been making mods around it. I know it is sometimes easier for some modders to not update and stay on older versions like 1.18.2 or 1.12.2, but I think that changing to 1.19.2, which is right before 1.19.3 - a road block for the new versions, is the greater idea. So I vote for it to become a new LTS for forge.

UPD: A thought just came to me, that most people have already updated their important for modpacks mods to 1.19.2 and actually it adds a +1 coin to switching to that one as LTS. 

Edited by Timebender
  • Like 1
Link to comment
Share on other sites

  • Curle locked this topic
Guest
This topic is now closed to further replies.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • Hello everyone, I'm making this post to seek help for my modded block, It's a special block called FrozenBlock supposed to take the place of an old block, then after a set amount of ticks, it's supposed to revert its Block State, Entity, data... to the old block like this :  The problem I have is that the system breaks when handling multi blocks (I tried some fix but none of them worked) :  The bug I have identified is that the function "setOldBlockFields" in the item's "setFrozenBlock" function gets called once for the 1st block of multiblock getting frozen (as it should), but gets called a second time BEFORE creating the first FrozenBlock with the data of the 1st block, hence giving the same data to the two FrozenBlock :   Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=head] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@73681674 BlockEntityData : id:"minecraft:bed",x:3,y:-60,z:-6} Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=3, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=2, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} here is the code inside my custom "freeze" item :    @Override     public @NotNull InteractionResult useOn(@NotNull UseOnContext pContext) {         if (!pContext.getLevel().isClientSide() && pContext.getHand() == InteractionHand.MAIN_HAND) {             BlockPos blockPos = pContext.getClickedPos();             BlockPos secondBlockPos = getMultiblockPos(blockPos, pContext.getLevel().getBlockState(blockPos));             if (secondBlockPos != null) {                 createFrozenBlock(pContext, secondBlockPos);             }             createFrozenBlock(pContext, blockPos);             return InteractionResult.SUCCESS;         }         return super.useOn(pContext);     }     public static void createFrozenBlock(UseOnContext pContext, BlockPos blockPos) {         BlockState oldState = pContext.getLevel().getBlockState(blockPos);         BlockEntity oldBlockEntity = oldState.hasBlockEntity() ? pContext.getLevel().getBlockEntity(blockPos) : null;         CompoundTag oldBlockEntityData = oldState.hasBlockEntity() ? oldBlockEntity.serializeNBT() : null;         if (oldBlockEntity != null) {             pContext.getLevel().removeBlockEntity(blockPos);         }         BlockState FrozenBlock = setFrozenBlock(oldState, oldBlockEntity, oldBlockEntityData);         pContext.getLevel().setBlockAndUpdate(blockPos, FrozenBlock);     }     public static BlockState setFrozenBlock(BlockState blockState, @Nullable BlockEntity blockEntity, @Nullable CompoundTag blockEntityData) {         BlockState FrozenBlock = BlockRegister.FROZEN_BLOCK.get().defaultBlockState();         ((FrozenBlock) FrozenBlock.getBlock()).setOldBlockFields(blockState, blockEntity, blockEntityData);         return FrozenBlock;     }  
    • It is an issue with quark - update it to this build: https://www.curseforge.com/minecraft/mc-mods/quark/files/3642325
    • Remove Instant Massive Structures Mod from your server     Add new crash-reports with sites like https://paste.ee/  
    • Update your drivers: https://www.amd.com/en/support/graphics/amd-radeon-r9-series/amd-radeon-r9-200-series/amd-radeon-r9-280x
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.